Grok zero-width space remover

Grok's answers are displayed through X's own rendering layer, which commonly inserts a non-breaking space between a number and its unit to prevent the pair from breaking across two lines, and applies automatic linkification to handles, tickers and hashtags that can leave a stray invisible character at a link boundary. Neither behaviour originates with Grok itself; both are properties of the platform hosting the reply.

This tool detects and removes the zero-width space along with the related family of invisible codepoints, regardless of which platform behaviour introduced them, without altering any character that actually renders. Detection and removal both run client-side, in JavaScript, with no upload and therefore no run limit.

There's nothing to preview beforehand, since the whole category of problem is invisible until the scan runs.

Step 1

Paste the answer copied from Grok on X, or from the standalone app, into the input field.

Step 2

Run the removal. It executes instantly, locally.

Step 3

Read the result. Every rendered character is unchanged.

X applies a consistent display treatment to numeric values across the entire service, substituting a non-breaking space for the ordinary one between a figure and its unit to control line-wrapping behaviour. Grok's replies are rendered through this identical path, independent of anything the underlying model generated, which is why the same artefact appears in an ordinary post as well as in a Grok answer.

This differs from a chat interface where formatting originates with the model's own output rendering. Here, the platform imposes structure on the reply after generation, and that structure is what introduces the invisible character.

This tool removes the zero-width space, U+200B, along with the zero-width joiner and non-joiner, the word joiner, the byte-order mark, the soft hyphen, and the non-breaking, narrow and hair spaces, the family that includes the specific non-breaking space X inserts around numeric units.

A joiner detected inside a genuine emoji sequence is preserved rather than removed, since stripping it would visually split the composed emoji apart. The space-like characters in the set are replaced with an ordinary space rather than deleted outright, so word boundaries and line wrapping remain correct.

Inside a heading or a URL slug, a hidden character splits the string for any process comparing it byte by byte: full-text search, a regular expression, a string equality check. Two values that render identically fail to match, because one carries a codepoint the other does not.

A numeric value copied from a Grok answer with a non-breaking space in place of an ordinary one can fail a parser or a spreadsheet formula expecting standard whitespace, despite looking identical to a correctly formatted figure.

These characters are overwhelmingly incidental: byproducts of X's platform-wide rendering of numbers, units and links rather than markers deliberately embedded to identify a passage later. Their presence indicates that text passed through that rendering layer; it does not indicate who wrote the underlying words.

A genuinely different research area, statistical watermarking, biases which tokens a model is more likely to select across an entire passage, leaving a pattern distributed through ordinary word choice rather than a discrete character. No character-level scanner, including this one, can detect or affect that kind of watermark, and no tool on this site claims otherwise.

Analysts pulling a figure out of a Grok answer into a spreadsheet run it through here first, since a non-breaking space adjacent to a number can silently defeat a formula expecting ordinary whitespace. Publishing and SEO teams use it when a heading pulled from Grok stops matching its slug for no apparent reason.

It is standard practice in any workflow performing programmatic comparison on Grok-sourced text: deduplication, data validation, database imports, anywhere two values that should be logically identical need to actually match byte for byte.