Llama zero-width space remover

A zero-width space occupies a position in text while rendering nothing visible. This tool scans text copied from a Llama-based interface for U+200B and the small family of related invisible characters that accompany it, and removes them, leaving visible words in their original positions.

Processing runs client-side, in JavaScript, entirely within your browser. There is no upload and no server round trip, and accordingly no run limit.

Llama is a model family rather than a single hosted product, so a reply may arrive through a self-hosted web UI, a desktop application, a hosted playground, or a custom application built on the API. Each wraps the raw output in its own markdown renderer, and each renderer's formatting decisions, for a list, a code block, a heading, can introduce a non-breaking or zero-width character as a side effect.

The specific mixture of invisible characters in a given reply is therefore a function of the rendering frontend rather than of the underlying model. A minimal interface passing the model's raw output through with little modification sits at one end of that range; a heavily styled chat application rebuilding the reply as rich HTML sits at the other, with substantially more opportunity to introduce a stray character.

Nothing to preview beforehand, since the issue is invisible until the tool runs.

Step 1

Paste the text from whichever Llama interface produced it into the input field.

Step 2

Run the removal. It executes instantly, locally.

Step 3

Read the result. Every visible word remains exactly as it was.

U+200B is the character most commonly meant by the name, but it seldom appears in isolation. This tool also removes the zero-width joiner and non-joiner, the word joiner, the byte-order mark, the soft hyphen, and the family of non-breaking, narrow and hair spaces that render as an ordinary gap while occupying a distinct codepoint.

A joiner within a genuine emoji sequence is preserved, since its removal would visually split the emoji, and space-like characters are substituted with an ordinary space rather than deleted, preserving correct wrapping and word boundaries.

Within a heading or a URL slug, a hidden character splits the string for any byte-level comparison: search, a regular expression, an equality check. Two visually identical values fail to match because one carries a character absent from the other.

In a pipeline diffing model output across runs or prompts, a character introduced by the rendering layer rather than the model can register as a spurious difference, a persistent source of noise in automated comparison.

No. Llama is open-weight, and no single controlled copy path exists through which a deliberate marker could be introduced. These characters are overwhelmingly a side effect of whichever frontend rendered the text, independent of authorship or of which model produced it.

Separately, genuine research into watermarking biases which words a model is statistically more likely to select across a passage, a pattern embedded in the writing itself rather than in any discrete character. No tool scanning for invisible Unicode, this one included, can detect or affect that kind of statistical watermark.

Engineers building an application on a self-hosted Llama model run this before comparing output across runs, since a rendering-introduced character can register as a false difference in a diff.

Anyone performing programmatic comparison, deduplication, or data validation processes Llama-sourced text through this tool first, ensuring values that should be identical actually match.