Why does a URL that looks fine still 404?
Because an invisible Unicode character makes it a different URL than the one you can see. Characters like a zero-width space (U+200B) or a non-breaking space (U+00A0) render as nothing, so a slug typed or pasted with one embedded in it looks identical to the clean version on screen, in a chat message, or in a spreadsheet of URLs. But a server does not compare URLs by how they look — it compares the exact byte sequence, and the invisible character is still part of that sequence, usually surviving as a percent-encoded triplet like %E2%80%8B. If no route matches that exact path, the request 404s even though a human reading the link sees nothing wrong.
How does an invisible character end up in a slug?
Almost always through pasting, not typing. A common path: someone copies a headline out of ChatGPT, Word, or Google Docs — any of which can carry a zero-width space, a non-breaking space, or a byte order mark from the source formatting or the model's own output — and pastes it straight into a CMS title field that auto-generates the URL slug from it. Most slugify functions lowercase text and turn ordinary spaces into hyphens, but they were written expecting ASCII whitespace, not the dozen or so Unicode code points that also render as blank space. A character the function doesn't recognize as whitespace to collapse just gets carried through into the published URL, invisible and intact.
The full set of code points that can do this — zero-width space, non-breaking space, soft hyphen, byte order mark, and others — is covered in the complete invisible Unicode characters list.
Is this a documented problem?
Yes. The organization that maintains the URL parsing standard used by every major browser has a report on exactly this. An issue filed against the WHATWG URL Standard on October 13, 2016 showed that inserting a zero-width space into an otherwise ordinary GitHub URL — between two words in the path — produced a 404, because the parser percent-encodes the character instead of treating it as equivalent to no character. The bug report notes that these cases are unusually hard to track down, since the character isn't visible in a browser's address bar, and confirming it requires a hex editor or a character-level tool.
What does this cost a site, specifically?
| Symptom | Why it happens |
|---|---|
| Shared link 404s | The link was copied from a place that already had the invisible character baked into the slug (an email, a chat message, a spreadsheet), so it never matched a real route. |
| Two URLs for one page | A redirect or CMS fallback quietly serves the same content at both the clean slug and the one with the hidden character, splitting link equity between two indexable URLs instead of one. |
| Analytics undercount a page | Traffic to the byte-for-byte-different URL logs as a separate page in most analytics tools, so a single article's real traffic looks split across two rows. |
| Sitemap and internal-link mismatch | An internal link built from the raw pasted title points to the slug with the invisible character while the sitemap generator normalizes it away (or vice versa), so the two disagree about which URL is canonical. |
None of this requires Google's index to be "confused" by the invisible character — the ordinary mechanics of duplicate URLs cause it. Google's own documentation on consolidating duplicate URLs covers exactly this class of problem: pick one canonical URL, 301-redirect or rel=canonical the others to it, and stop generating new duplicates at the source.
How do you find and fix it?
You can't spot this by looking at a rendered link — the character is invisible by design. Copy the actual slug string (not the link text) out of your CMS and paste it into the checker at the top of this page: any zero-width space, non-breaking space, soft hyphen, or byte order mark shows up as its own named row with its exact code point, and the cleaner strips it, leaving the rest of the slug untouched. For a title you're about to publish, run it through the cleaner before it ever reaches the slug field — that stops the duplicate URL from being created in the first place, which is easier than untangling one after Google has indexed both.
If the pasted text is going straight into code, JSON, or a CSV import rather than a slug field, the same invisible characters cause a different class of failure — see sanitizing copied text for code, JSON, and CSV for that case.