Whitespace visualizer
See the tabs, odd spaces, and line endings hiding in your text.
Ordinary spaces between words are left alone, so what stands out is what is actually unusual: tabs, no-break and other exotic spaces, zero-width characters, whitespace at the end of a line, and the line endings themselves. The result is the marked text, so copying it pastes the markers into a bug report or a message. Up to 200,000 characters.
Result
Start typing and the result appears here. No button needed.
Whitespace visualizer, without the extra steps.
Make the invisible parts of a text visible: tabs, no-break and other exotic spaces, zero-width characters, whitespace left at the end of a line, and whether each line ends the Windows way or the Unix way. By default ordinary spaces are left alone so what is actually unusual stands out, with a legend naming every marker on screen.
How to use this tool
- 1Paste the text whose spacing you need to see.
- 2Keep Only the unusual for a document, or choose Every space too for a short snippet.
- 3Read the markers against the legend, and copy the marked text into a bug report if you need to show someone.
When Whitespace visualizer is the right tool
- A YAML or Python file will not parse and the error says indentation, but every line looks the same.
- A value copied from a web page refuses to match its twin, and something invisible is in it.
- A diff shows an entire file as changed when only one line was edited.
- A snippet has to go into a bug report with its exact spacing preserved, so the reader can see it too.
Marking everything hides the problem
A view where every space is a dot is the conventional one, and it is the wrong default: a page of dots is as unreadable as a page without them, and the thing you are hunting is never an ordinary space between two words. Only the unusual marks the four kinds that actually break things — a tab among spaces, a no-break space pasted from a browser, a zero-width character, and whitespace left at the end of a line — and leaves normal prose looking like prose, so one odd marker in a wall of text is obvious.
The line ending is part of the answer
Two files that differ only in line endings look identical and diff as entirely changed. Each line ending is marked here, and Windows and Unix endings get different markers, so a file that mixes them is visible at a glance — the workspace also says so in a sentence when both appear. One caveat worth knowing: a browser textarea rewrites pasted line endings to the Unix kind before any tool can see them, so the Windows marker shows up mainly on text supplied through the agent input.
This shows, it does not fix
The result is your text with markers in it, which means copying it gives you something to paste into a bug report or a chat message where the other person can see exactly what you see. It also means the output is not a cleaned-up version of your text. Once the marker has told you what is wrong, Trim whitespace removes line-edge whitespace, Find and replace swaps a specific character, and Remove empty lines handles blank lines.
A few quick answers.
A legend appears under the result listing only the markers actually in it: · for a space, → for a tab, ␣ for a no-break or other exotic space, ∅ for something with no width at all such as a zero-width space, and ↵ or ␍↵ for a Unix or Windows line ending. Each one carries its count.
Because a document of dots is unreadable, and the question is almost always which space is the wrong kind rather than where the spaces are. Only the unusual marks tabs, exotic spaces, invisible characters, and whitespace at the end of a line — the four that cause problems. Every space too exists for short snippets where exact spacing matters.
No, this only shows. Trim whitespace removes the whitespace at line edges, Find and replace will swap a specific character once you know which one it is, and Remove empty lines deals with blank lines. Seeing the problem first is what makes those safe to apply.
Because the textarea normalised them when you pasted. Browsers rewrite CRLF to LF in form fields, which no tool on the page can undo. When line endings are the actual question, supply the text through the agent input, where nothing rewrites it on the way in.
No. A tab is marked with a single arrow rather than being expanded to the next tab stop, because how wide a tab appears depends on the editor reading it — which is exactly why mixing tabs and spaces causes trouble. The marker tells you a tab is there; your editor's settings decide what it looks like.
Anything in Unicode's space category that is not the ordinary space: no-break spaces, en and em spaces, the narrow no-break space, the ideographic space. They are marked ␣ and counted separately, because they look like spaces, survive copying, and are rejected by parsers that expect an ordinary one.