The text is split into Unicode code points rather than UTF-16 units, so emoji and supplementary-plane characters are not cut in half. Each code point is checked against a curated set of troublemakers - zero-width and bidirectional format characters, the byte order mark, non-ASCII spaces, C0 and C1 control characters, and Cyrillic or Greek letters that imitate Latin ones. The whole string is separately checked for mixed line endings and for Unicode normalization other than NFC.
A CSV import fails on the first column. An API key pasted into a config file never authenticates. Two passwords look identical but one is rejected. A git diff marks every line as changed. A regular expression does not match a word that is clearly there. In each of these the text is not what it appears to be, and no tool that relies on looking at it can help.
Everything runs in your browser. The text you paste is never sent to a server, never written to storage, and never included in analytics. That matters here because the strings people bring to this tool are often API keys, tokens and passwords.
Common questions and answers about this topic.
Paste the text into the left panel. The summary flags at the top of the result panel tell you how many kinds of problem were found; clicking a flag jumps to the first occurrence. The character-by-character view below shows each suspicious code point as a clickable marker, and selecting one explains what it is and what to do about it.
It is a formatting character that renders with no width at all, originally intended as a line-break opportunity. To a person it is not there; to a program it is one more code point in the string. That is why an email address or an API key with a zero-width space in the middle looks perfectly correct on screen yet never matches the stored value.
In practice five keep coming back: U+200B zero-width space and its relatives, U+00A0 non-breaking space from copying web pages, U+FEFF byte order mark at the start of a file, U+3000 full-width space from East Asian input methods, and Cyrillic or Greek letters that imitate Latin ones. This tool flags each of them, along with C0 and C1 control characters and typographic spaces such as thin space.
A regular space is U+0020, the one your space bar produces. A non-breaking space is U+00A0 - it looks the same but tells the renderer not to break the line there, and it commonly arrives when copying from a web page. A full-width space is U+3000, visibly wider, produced by East Asian input methods. All three render as blank, but only U+0020 is matched by an ASCII space pattern, so the other two silently break trimming, splitting and column parsing.
There are two independent causes. The first is a stray invisible character in one of them - a zero-width space, a non-breaking space or a BOM. The second is Unicode normalization: the letter é can be a single code point (NFC) or the letter e followed by a combining accent (NFD). Both render identically, but they are different sequences and byte comparison fails. macOS filenames and some input methods produce NFD, so text moving between systems can silently switch form. This tool flags both causes.
It checks a curated set of characters that are known to break things - zero-width and bidirectional format characters, the BOM, non-ASCII spaces, C0 and C1 control characters, and Cyrillic or Greek lookalikes - plus mixed line endings and non-NFC normalization across the whole string. It does not modify your input, does not upload anything, and is not a full Unicode linter: rare or script-specific issues outside that curated set are not flagged. The cleaned-text copy is a convenience, not the main result; the main result is the diagnosis.