Valheim Co-op Portal Hub Label Convention

What a portal label must answer in five seconds

A useful portal name answers three questions without a second sign: where does this door exit, what kind of place is that exit, and is it safe to travel there with light gear. Jokes, inside references, and single-word names fail the five-second test when a new player joins mid-session. Prefer a short, boring pattern the whole group can type the same way every time.

Write labels for the traveler, not the builder. The person who placed the portal already knows which stone circle leads to the shipyard. The traveler who just died in the Mountains and is under-fed needs the destination in the name, not a riddle. If the group wants flavor text, put it on a separate sign next to the portal, not inside the portal name field itself.

Keep client language consistent. If one player types "Swamp Fort" and another types "swamp fort" and a third uses a local-language synonym, the hub still works mechanically, but the written map and voice callouts diverge. Pick one language for labels, one capitalization rule, and one separator character, then stop negotiating every session.

Assume the traveler may be muted, on another platform, or reading the hub while someone else is mid-fight. The label has to work as text alone. Voice can clarify exceptions; it should not be required to decode every door.

A reusable naming pattern

Use a three-part pattern: BIOME-ROLE-TAG. Biome is a short code for the destination biome or landmark class. Role is what the destination is for. Tag is a short unique token when two destinations share biome and role. Separators are hyphens with no spaces, so names stay compact in the portal UI.

Suggested biome codes for a small group: MF (Meadows), BF (Black Forest), SWP (Swamp), MTN (Mountain), PLN (Plains), MST (Mistlands), ASH (Ashlands), OCN (ocean or ship-related), HUB (main portal room). Role words worth locking: BASE, ORE, FOOD, BOSS, FARM, DOCK, RAID, TEMP. TEMP means the destination is disposable and may be removed without updating long-term maps.

Tags exist so two swamp bases do not collide. Do not encode plot spoilers into tags if the group wants a spoiler-light world; use A1, B2, N2 style tokens and keep the lore name on a private note. When a TEMP portal is promoted to permanent, rename both ends in the same session and rewrite the hub map line; do not leave the old TEMP name in the UI.

Pair names must match on both ends of a portal link. The remote portal that returns to the hub should say HUB-MAIN (or your chosen hub code), and the hub-side portal should say the destination code. Write both names on the map before anyone crafts the second portal, so a half-finished link is visible as an unfinished row rather than a mystery door.

Build the one-page hub map before the next session

A hub map is a single shared note, not a screenshot album. Columns that matter: portal name on the hub side, expected remote name, biome/role, who owns maintenance, last verified date, and a one-line hazard note (for example "no food chests" or "near patrol path"). Keep it where the group already coordinates—chat pinned message, shared doc, or server MOTD—so it is not trapped on one player's desktop.

Verify by walking, not by memory. Once per week, or after any portal rebuild, one player stands in the hub and steps through each door while a second player ticks the map. If the exit does not match the row, fix the name or the map before adding new portals. Unverified rows are worse than missing rows because they create false confidence.

Limit hub density. A room with twelve unlabeled doors trains people to ignore labels. Prefer a small permanent set plus a clearly marked TEMP wall. When the TEMP wall fills, archive or delete links instead of inventing a second informal dialect. The guides index on this site includes broader base and logistics topics if the group is redesigning the physical hub layout rather than only the names.

Record ownership. "Who rebuilds this if it breaks" prevents a dead door from sitting unlabeled for days. Ownership is a maintenance role, not a claim on the destination base. If the owner is offline for a long stretch, reassign the row on the map rather than waiting for a voice apology.

Join checklist for the next player through the door

Before a session that uses the hub heavily, run a short verbal or text checklist:

• Confirm the game and server build string the group is using, and that everyone matched that string before connecting.
• Confirm the hub map date matches today's session; if someone rebuilt portals yesterday, re-verify before a boss run.
• Confirm food, portal tin/copper needs, and whether TEMP links are allowed this session.
• Confirm a return path: every new remote portal must have a labeled return to HUB-MAIN before the builder leaves the area.
• Confirm mute-friendly labels: no session depends on a joke name that only two people understand.

When a join fails or lands in the wrong place, treat it as a map defect first. Check the portal name pair, then the map row, then the physical placement. Do not start a multi-variable rebuild until the naming mismatch is ruled out. For connection-stage vocabulary when the problem is joining the session rather than reading a portal, see the same-site article on crossplay join stage vocabulary.

Boss-prep sessions deserve a stricter rule: freeze hub renames for the hour before the fight. Renaming mid-prep creates a window where voice callouts and door labels disagree. Schedule renames after the run, with a fresh map verification pass.

Failure modes this convention is meant to prevent

The first failure mode is the "portal3" wall: mechanically fine, socially useless. The second is the joke-name wall: funny once, expensive when someone portals into a biome under-geared. The third is asymmetric naming, where one end says HUB-MAIN and the other still says an old joke, so rebuilding a broken link becomes archaeology.

A fourth failure mode is screenshot-only documentation. Screenshots go stale the moment someone moves a portal. Prefer a text map with a last-verified date. A fifth is mixing languages and separators in the same hub, which quietly splits the group into people who can parse the system and people who ask in chat every time.

This convention does not replace good portal placement, defense, or ore logistics. It only makes the existing network readable. If the group needs help deciding how many portals to maintain versus carting ore, use the logistics guides on this site rather than stretching a naming scheme into a full transport plan.

Assumptions and limits

All example names and codes are hypothetical planning aids. Portal UI limits, localization, and build-specific behavior can change; this article does not inventory those limits for a named patch. The convention assumes a cooperative group that can agree on English labels and a shared note. It is not advice for public servers with hostile players, not a modding guide, and not a substitute for Iron Gate support channels when something looks like a product bug. No hands-on testing of a specific Valheim build was performed for this page; treat the pattern as a social workflow, then adapt codes to your world's biomes and landmarks.

Sources and method

• Iron Gate: Valheim FAQ — retrieved 2026-10-19
• Iron Gate: Valheim support — retrieved 2026-10-19

AI-assisted writing with automated source, calculation and editorial checks. No hands-on testing or professional certification is claimed. Check the stated assumptions before applying this guide.