How to find and remove zero-width spaces

A zero-width space has no width and no glyph. Its job is to tell software that a line may break at that point, and on screen it looks like nothing at all. That is why it causes trouble when it ends up somewhere nobody put it on purpose: the text reads normally, and the software reading it sees something else.

Its code point is 200B. Most editors draw nothing for it, so the reliable way to find one is to search for that code. Word, Google Docs and VS Code each spell the search differently, and that difference is most of what this guide covers.

How to tell a document has one

• A search for a word you can see on the screen finds nothing, or finds it in some paragraphs and not in others.
• A word counter reports one word more than you count. Unicode’s word-boundary rules treat a zero-width space as a break, so one word becomes two.
• Walking through a word with the arrow keys takes an extra keypress at the same spot, because the cursor is stepping over a character you cannot see.

Each of these has other possible causes. To confirm, paste the passage into our Invisible Character Detector, which lists every zero-width space with its position without changing your text. Then fix it at the source, in the document itself, so the next copy is clean too.

In Microsoft Word

Word’s Find and Replace accepts a character code: a caret, the letter u, and the number of the character. The catch is that Word expects the number in decimal, not in the hexadecimal form Unicode uses. 200B in hexadecimal is 8203 in decimal, so the search term is ^u8203. Volunteer moderators on Microsoft’s own support forum give exactly this code and this warning about decimal.

• Open Find and Replace with Ctrl+H, or from Home, then Editing, then Replace. On a Mac the basic pane opens with Control+H.
• In Find what, type ^u8203.
• Leave Replace with empty.
• Choose Replace All.

If you already have one of the characters in the document, there is a second route. Copy it, paste it into Find what (the box will look empty), and Find Next will still land on each instance.

Before replacing all of them, check where they sit. Word users have long been advised to insert zero-width spaces after the slashes of a long URL, so that it can wrap at the end of a line. In that position the character is working. Remove it and the address still reads the same, but it will wrap differently.

In Google Docs

Google Docs has no caret codes, but its Find and replace accepts regular expressions, and Google’s help page states that its products use the RE2 syntax. RE2 writes a character by its hexadecimal code point inside braces, so a zero-width space is \x{200B}.

• Open Edit, then Find and replace.
• In Find, type \x{200B} and tick Match using regular expressions.
• Leave Replace with empty, then choose Replace all.

One limit applies to the other box. Google’s help says regular expression replacements only work in Google Sheets, and anything typed into Replace with in Docs is inserted as literal text. An empty replacement is unaffected, which is all this job needs.

In VS Code

VS Code does part of the work before you search. Since version 1.63, released for November 2021, it highlights uncommon invisible characters by default. The setting behind it is editor.unicodeHighlight.invisibleCharacters; if a file shows no highlight where you expect one, check that it has not been turned off.

To remove them, open Find, or Search across the workspace, switch on the regular expression toggle and search for \u200B, with an empty replacement. The same pattern works in both places even though they run different engines. The project’s wiki explains that open files are searched with a JavaScript regular expression, while the workspace search runs ripgrep on the Rust regex engine. JavaScript reads \u followed by exactly four hexadecimal digits as a character, and so does Rust.

When to leave it where it is

The searches above match the zero-width space and nothing else, which is deliberate. Its neighbours do different jobs. The zero-width joiner is what holds many emoji sequences together, and without it they fall back to separate emoji. A non-breaking space keeps a number next to its unit. Widen the search to every invisible character and you will break both.

Our Unicode Cleaner makes that distinction by default. It removes zero-width spaces, byte-order marks and soft hyphens, turns non-breaking spaces into ordinary spaces, and leaves the three joiners alone unless you opt in. Compare its output with the original in the Text Diff Checker before you paste anything back.

Characters this search will not find

Two recent stories are about different characters, and the search for 200B misses both. In April 2025 the startup Rumi reported that OpenAI’s o3 and o4-mini models were leaving narrow no-break spaces in long answers. That character has a width and a different code point, 202F, so in Word the search becomes ^u8239, in Google Docs \x{202F} and in VS Code \u202F.

In September 2026 Microsoft described a phishing campaign that hid Unicode tag characters inside words such as “funding” to slip past keyword filters. Tag characters sit far outside the range above, and our own detector does not look for them either. Microsoft’s advice for anything that matches on keywords is short: “normalize before you match.”

None of these characters says who wrote a text. A zero-width space can come from a web page, a word processor or a careful typesetter, and removing one changes how the text behaves, not where it came from.