Find invisible characters and byte order marks

Knowing they exist is not the same as knowing where they are

Almost every tool in this category answers one question: does this text contain hidden characters, yes or no. That answer is nearly useless. If you already suspect something is wrong — a lookup that fails against a value you can see with your own eyes, a CSV whose first column header refuses to match, a password your manager accepts and the login form does not — then "yes, there is something" tells you nothing you had not already worked out.

This tool renders your text back to you with every hidden character replaced by a visible marker you can hover or tap. The marker gives the Unicode name, the code point, the line and column, and one sentence about what the character does and where it usually comes from. A zero-width space stops being a mystery and becomes a thing sitting between the e and the r on line 14.

The byte order mark, and why it is the same bug as your broken CSV

A byte order mark is three bytes — EF BB BF in UTF-8 — that sit at the very front of a file and announce its encoding. In that position it is not a bug at all. It is the reason Microsoft Excel can open a UTF-8 spreadsheet and showå instead of Ã¥. Save the same file as UTF-8 without a BOM, double-click it in Excel on Windows, and every accented character in it turns to mojibake, because Excel falls back to the system code page when nothing tells it otherwise. That single behaviour is behind a very large share of the "my CSV is broken" reports in the world, and it is the same problem ourCSV viewer exists to make visible. If the mechanics are new to you, the byte order mark explained covers it properly, and what a CSV file actually is covers the format around it.

A byte order mark anywhere other than the first character is a straight bug, and it is common. Concatenate two UTF-8 files with a shell redirect and the second file's BOM lands in the middle of the result. Read a file with a BOM-unaware parser and the mark becomes part of your first field name, so "id" is silently"id" and every lookup against it misses. Paste a snippet with one into a shell script and the shebang line stops being a shebang line. Because the two cases are genuinely different, this tool reports them separately and defaults to keeping the leading mark while stripping the strays.

Removing everything is the wrong default

The other common design failure in this category is a single button that strips every non-ASCII character it can find. That destroys work. A non-breaking space is usually deliberate: it is what holds 10 kg, Fig. 4 andChapter 7 together so a line break cannot split them, and a typesetter put it there on purpose. A zero-width joiner is load-bearing in a different way — emoji sequences are built from it, and removing the joiners from a family emoji turns one glyph into four separate people. A zero-width non-joiner carries real meaning in Persian, Arabic and several Indic scripts.

A zero-width space, by contrast, is almost never intentional. It arrives from content management systems, from Jira, from word processors and from copy-paste out of rendered HTML, it occupies no space at all, and it makes two strings that look identical compare as different. So the defaults here are set per character type, after what is usually correct rather than after what is easiest to build: zero-width spaces, stray byte order marks, control codes, directional overrides and soft hyphens go; non-breaking spaces, zero-width joiners and look-alike letters stay. Each one is a dropdown, and several offer a third option that is neither keep nor delete — turn a soft hyphen into a real hyphen, turn a line separator into an ordinary newline, turn a thin space into a plain space.

Homoglyphs, and why mixing scripts is the actual signal

A homoglyph is a character from one script that renders identically to a character from another. Cyrillic а at U+0430 is indistinguishable from Latina at U+0061 in every font you are likely to be reading this in. Greek omicron, Armenian oh and the full-width forms do the same job. Registering a domain that swaps one Latin letter for its Cyrillic twin is the oldest trick in phishing, and it works because there is nothing to see.

Detection has to be smarter than "flag every non-Latin letter", though, or it drowns in false positives — a Russian word is entirely Cyrillic and entirely innocent. The signal is mixing: one foreign letter dropped into an otherwise Latin word. This tool flags mixed-script words separately, shows the Latin reading beside the original so the substitution is visible rather than described, and lists every look-alike it found with the character, what it looks like, which script it actually belongs to and its code point. If you want the underlying model,what Unicode is and how it works explains why two characters can share a shape and nothing else.

The directional characters belong to the same family of problems. U+202E, the right-to-left override, reverses the display order of everything after it, which is how an executable gets a filename that reads as a document while the operating system still runs it as a program. Anything that renders a filename, a display name or a commit message and does not strip these is repeating a very old mistake, and this tool shows them explicitly rather than as a generic warning.

What it does not do

It does not generate invisible characters for you to paste into a username or an empty chat message. That is a different tool for a different purpose, and it is not one we are interested in building. It also does not attempt to fix mojibake — text where UTF-8 bytes were decoded as Windows-1252 — beyond flagging the C1 control codes that give it away; repairing that needs the original bytes, not the mangled string.

Nothing you paste is transmitted. The scanner is JavaScript running in this tab, there is no upload endpoint, and you can check that yourself: open your browser's network panel and paste something. No request appears, because there is nowhere for one to go. That matters more here than for most text tools, since the text people bring to a hidden-character check is disproportionately passwords, API keys, customer records and suspicious email headers.