Steamworks Sentence External Links: How They Work and Why They Break

Steamworks does not have a field called "sentence external links." The term describes what developers actually do: placing clickable external URLs inside a sentence of store-page text, patch notes, or Workshop descriptions, then watching some of them fail to render or resolve. The mechanism behind those failures is concrete, testable, and fixable, and most 900-word explainers skip it entirely.

A Steamworks external link is a plain-text URL or BBCode tag that Steam's renderer converts into an anchor element. Whether it displays depends on four things: the field you type it into, Steam's BBCode parser, the client's link-filter step, and the destination server's response. Break any one and the link either vanishes or dead-ends. This explainer walks through each stage, quantifies where links appear and fail, covers edge cases, and gives you a pre-publish checklist. The subject is low-risk science and engineering documentation, so no medical or legal disclaimer applies.

Mechanism: how Steam turns text into a clickable link

Steam store pages and announcement posts accept a limited BBCode subset, not HTML. The parser recognizes [url], [url=...], and [b], [i], [u], [h1] through [h3], plus [list], [olist], [*], [img], [quote], [code], and [spoiler]. Raw HTML is stripped or escaped. A bare URL like https://example.com usually autolinks in announcement bodies but not reliably inside all store fields.

Three separate surfaces render text differently, and this is the professional caveat most guides miss. The Steam client, the Steam website, and the mobile app can each apply slightly different anchor-construction rules. A link that works in the desktop client may open in an in-app browser on mobile with a different URL encoding. The parser also strips trailing punctuation in some builds, so a sentence-ending period after a raw URL can become part of the href.

The underlying pipeline is: input text → entity sanitization → BBCode tokenization → anchor generation → client-side link filter. Security filtering blocks certain schemes. http and https resolve; javascript:, data:, and file: are rejected. Steam also warns or intercepts links to domains it flags, and it shows a confirmation page for external navigation from some surfaces.

Plain-language version: you are not typing a link into a page, you are feeding text into a four-stage filter and hoping the output anchor survives.

Quantified context: where external links appear and how often they fail

Steam's public documentation defines the accepted BBCode tags but does not publish render-failure rates. Without supplied telemetry, no honest source can claim a precise failure percentage. What can be quantified is the number of distinct fields and the known failure modes per field.

Store page text lives in fields such as short description, about-the-game, and system requirements. Each has a character budget, and the short description is truncated in list views, which cuts links mid-href. Announcement bodies allow longer formatted text and are the most reliable surface for inline links. Workshop descriptions allow BBCode and external URLs with fewer truncation events. Developer and publisher home-page fields accept a single URL each. Community hub and curator pages follow their own rules.

The table reconciles the main thresholds you will hit: truncation (character-budget), scheme validation (http/https only), and domain filtering (client-side). Treat them as three separate gates, not one.

Edge cases: punctuation, encoding, and redirect chains

The most common silent failure is a URL glued to punctuation. In a sentence like "see the guide at https://example.com/guide," the comma can be captured into the href by some renderers, producing a 404. The fix is spacing or BBCode-wrapping the URL so the closing tag defines the boundary.

Ampersands are the second trap. A URL with ?a=1&b=2 must be written as ?a=1&b=2 in BBCode context on some surfaces, because the entity sanitizer runs before tokenization. Skip the escape and the second parameter is dropped, so the destination script receives half a query string.

Redirect chains matter too. Shorteners and multi-hop redirects can trip the client link filter, which may block a URL that resolves to a flagged domain after two or more hops. Prefer the final destination URL. Custom URL schemes (steam://) work only inside the client and break in web contexts.

A counterintuitive detail: a link can render perfectly and still fail for users on the mobile in-app browser if the destination uses a frame-blocking header. The link "worked" on your desktop test and died for half your audience. Test on the Steam mobile app, not just the client.

Misconceptions: what developers get wrong

The biggest misconception is that Steamworks "supports external links" as a universal feature. Support is field-specific and surface-specific. A link allowed in an announcement may be stripped from a store description field.

A second misconception is that markdown works. Steam uses BBCode, and markdown syntax like text is not parsed; it renders as literal text. The inverse error also appears: developers paste raw HTML anchor tags, which get escaped rather than rendered.

A third is that a working link in the Steamworks editor preview equals a working published link. The preview renderer and the live client are not identical builds. Publish to a hidden branch or draft announcement first.

Raw URL with no scheme renders as plain text, not a link. html and javascript schemes are stripped, sometimes silently. Truncated store descriptions cut hrefs at the character budget. Ampersands unescaped drop everything after the first parameter. Shortener redirect chains can trigger the client domain filter. Preview panels and live clients can differ in anchor behavior.

Practical actions: a pre-publish link checklist

Work surface by surface. For each external link, confirm the field accepts BBCode, then wrap the URL in [url] tags rather than relying on autolink. Escape ampersands as & inside BBCode contexts. Keep store short descriptions free of links, and put navigational links in the about-the-game section or announcements.

Test in three places before publishing: the Steamworks editor preview, the desktop client, and the Steam mobile app. Click through every link and confirm the final destination, not just the first redirect. Replace shorteners with canonical URLs. Check that http and https both work, and default to https.

For "continue reading" style links, avoid splitting a sentence across a link boundary; keep the anchor text contiguous. If a guide lives on an external site, host the canonical URL on a domain you control, then link to it directly. Monitor broken links quarterly, because destinations move even when Steam's text does not. Given the platforms named above, always verify the scheme and the mobile in-app browser rendering before you ship.

Limitations: what this guide cannot tell you

Steam's internal parser, link filter, and per-surface rules are not fully documented publicly, and they change without notice. No reliable public data quantifies link-failure rates by surface, so any specific percentage would be invented. The field rules described here reflect observed behavior and Steam's published BBCode documentation, not an official external-link specification.

Rendering behavior can also differ by client version, region, and account settings. Treat every checklist item as a hypothesis to verify in your own surfaces, not a guarantee. When in doubt, keep external links minimal, prefer canonical https URLs, and test on the exact clients your audience uses.