Keeping Links, @Mentions and #Hashtags Intact in Styled Text

Style a caption that includes a real link, an @handle, or a #hashtag without thinking about it, and you can quietly break it: a Unicode-substituted "https://example.com" is no longer the literal string a platform recognizes as a URL. Our Protect links and mentions toggle, on by default, exists specifically to prevent that.

What gets detected

• https:// and http:// URLs, including query strings — https://example.com/a?x=1&y=2 stays exactly that.
• www.-prefixed URLs.
• Ordinary email addresses (hello@example.com) — not every internationalized email form, by design; see limitations below.
• @mentions and #hashtags, including Unicode letters, marks, digits and underscores in the body — @creator_23, #café.

A worked example

Input: Check my site https://example.com/a?x=1&y=2 and follow @creator_23 #café, styled bold with protection on. Result: the surrounding words become bold Unicode characters; the URL, the mention, and the hashtag — including the accented é — are copied through completely unchanged, character for character.

How overlaps are resolved

When a candidate could match more than one category, we resolve it in a fixed order: URL, then email, then mention/hashtag. That's why a URL containing an @ (like https://user@example.com/path) is protected as one whole URL, not split into a URL plus a separate mention — and why an email's domain is never mistaken for a mention, and a URL's #section fragment is never mistaken for a separate hashtag.

What this doesn't do

• It's a convenience, not URL validation — detected text is preserved exactly, but we don't check that a link actually resolves, or that a handle actually exists on any platform.
• It doesn't recognize bare domains without http(s):// or www. (e.g. just "example.com" on its own), or every possible internationalized email address format.
• It never fetches a URL, resolves a domain, or reads a profile — detection is entirely local to your browser, on the text you typed.

Turning it off

If you want a link or handle to be styled too (some people intentionally style a handle for effect, for example), just switch the toggle off before copying — the rest of the pipeline works exactly the same, it simply stops excluding anything from styling.

Why this needed to be built carefully, not just "style everything"

A styled URL isn't just cosmetically different — it stops being a URL a browser or app will recognize and make clickable at all, because the underlying characters (Mathematical Alphanumeric Symbols, for a bold style, say) aren't the ASCII letters browsers parse as part of the https:// scheme. The same is true for an @mention: a platform's mention-detection logic is generally looking for exact ASCII @username patterns, and a styled version simply won't match, silently turning a working mention into plain decorative text that doesn't notify or link to anyone. Protection exists specifically to prevent styling from quietly breaking something functional without you noticing until after you've posted it.

How detection handles messy, real-world text

Ordinary prose puts punctuation right up against links and hashtags — a sentence ending in a period right after a URL, a hashtag immediately followed by a comma, a mention inside parentheses. The detector is built to recognize sensible token boundaries rather than grabbing trailing punctuation that's clearly part of the sentence, not the link — so "visit https://example.com." protects the URL without swallowing that final sentence-ending period into it, and "(follow @creator_23)" protects just the mention, not the surrounding parentheses. It's also built to never split an emoji sequence or a multi-character accented letter across a protection boundary, so a hashtag ending in an accented letter like #café stays intact as one clean token rather than being cut mid-character.

A worked example with overlapping candidates

Take Reach me at hello@example.com or https://example.com/hello#contact. The email address is detected and protected as a whole email, not misread as a mention pointing at "example.com". The URL's own #contact fragment is part of the protected URL, not pulled out as a separate hashtag — because URL detection runs first and claims that whole token before hashtag detection ever gets a chance to look at it. Both protected spans come through byte-for-byte in the final styled result, wherever in the sentence they appear.

What this looks like from the reader's side, not just the writer's

Protection matters just as much for whoever reads your styled text as for you. A follower tapping a link in your bio expects it to open a page; someone tapping an @mention expects it to jump to that person's profile. Both of those depend entirely on the platform recognizing the exact literal characters that make up a valid link or mention — a styled version that merely looks like a link won't behave like one no matter how convincing it looks, which is exactly the gap this feature closes before you ever post.

Where this feature came from

Protected-span detection exists because the alternative — styling everything uniformly and hoping links still work — is a genuinely common failure mode for fancy-text tools that don't think about it. A bio with a broken link because the whole thing got bolded is a small but avoidable annoyance, and one that's easy to miss until a follower tells you your link doesn't work. Building detection in as a default-on behavior, rather than an optional advanced setting, reflects that most people styling a caption or bio don't expect — and shouldn't have to know to prevent — their functional links breaking as a side effect.

Questions people actually ask

Does turning protection off ever change what's detected, or just whether styling is applied? Just the styling. Detection logic runs the same way either way; the toggle only controls whether detected spans are excluded from the style transform or included in it.

Will this protect a phone number or a physical address? No — detection is scoped to URLs, email addresses, @mentions and #hashtags specifically. Other data patterns aren't recognized as protected tokens in this version.

Can protected text still be seen before I copy it? Yes — protected spans are never hidden or marked with invisible characters in the copied output; what you see in the result is exactly what gets copied, including the exact, unstyled protected tokens sitting right in place among the styled words.