Find invisible characters and byte order marks

Knowing invisible characters 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.

Links are where these characters announce themselves most loudly, because a URL cannot carry them literally. A zero-width space that hitched a ride into an address is transmitted as %E2%80%8B, and that sudden run of escapes in the middle of an otherwise ordinary path is how most people first learn the character was ever there. Running the address through a URL decoder converts the escapes back into the character, and then this tool will name it.

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 behavior is behind a very large share of the "my CSV is broken" reports in the world, and it is the same problem our CSV 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 and Chapter 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. The emoji search copies the canonical complete sequence when you need an emoji without assembling its visible and invisible parts by hand.

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, zero-width non-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.

Punctuation that belongs to another writing system is a different case. Arabic commas, Greek question marks, Armenian full stops, CJK punctuation and the ideographic space are kept by default. Each is still reported and can be mapped to ASCII explicitly, but the default does not silently rewrite Arabic, Greek, Armenian or East Asian text.

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 Latin a 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 character counter keeps grapheme, code-point and UTF-8-byte totals separate when the question is length rather than identity.

Decorative compatibility characters are another, less deceptive reason for similar shapes to carry different code points. The fancy text generator exposes the exact Unicode output and refuses cross-script substitutions; use this detector when the job is to inspect suspicious or hidden input instead.

When the text is a naming shortlist rather than an incident to inspect, clean the words before registration research. The domain name finder transliterates the submitted word positions, combines them visibly and checks the selected registry endings; it does not treat a look-alike spelling as the same name.

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 leaves your machine. The scanner runs where you are sitting, this page carries no code capable of sending anything, and there is nowhere on the site that would take it — check for yourself by opening the network panel and pasting something in. 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.