The text that looks right but is not

There is a class of bug that survives code review, survives QA, and survives a hundred manual tests, because every human looking at the screen sees exactly what they expect to see.

The string is fine. The rendering is fine. The pixels are fine. And the code is still wrong.

Two things cause this more often than anything else I have debugged: characters you cannot see, and characters you cannot read.

The ones you cannot see

Somebody pastes a sentence into a ticket, into a commit message, into a form field. On their screen it looks like a normal sentence with normal spaces.

It is not. Somewhere in there is a non-breaking space instead of a regular one, or a zero-width space that nobody typed on purpose, or a hair space that arrived with a copy from a document editor. None of them render as anything. All of them change what your code sees.

The classic example is a comparison that fails for no visible reason:

"hello world" === "hello world" // false

Both strings print identically. One of them has an invisible character in the middle, and no amount of staring at the screen is going to find it. You need a tool that shows you the bytes.

When I need to reproduce this, I use a small reference of invisible characters I can copy from directly — spaces, symbols and the odd special characters — so the test case is a real character and not a guess. The reference itself is Glyphs. It is at https://glyphs.cc, and the copy buttons give you the exact character instead of you trying to type it.

The habit that pays off: when a comparison behaves strangely, dump the code points before you touch anything else. Nine times out of ten the answer is one byte you did not write.

The ones you cannot read

The second version of this bug is quieter. Nothing is broken, nothing throws, the tests pass. The problem is that the text is in a language where you cannot verify it, so nobody checks what it actually says.

If your product has any non-English interface, this is not an edge case, it is the normal case. A button label that was translated by a person who was guessing will pass every automated check you have, because the string is present, it is not empty, it fits in the layout. Nobody notices that it means something slightly different than what you meant.

Checking it needs a dictionary, not a spell checker. When I am unsure about a Japanese word or a phrase I wrote myself, I look it up together with the grammar and the kanji reading, because the same kanji can carry different readings and the sentence context decides which one is right. SKSensei does exactly that — dictionary, grammar, kanji and example sentences on one page — and the whole thing lives at https://sksensei.com.

The useful part is the sentence view. A word in isolation is not enough to tell whether your sentence is natural; you need to see it used. That is the difference between shipping a translation and shipping a word list.

Why the rendering is the problem

Both of these bugs share the same root cause: the screen is a lossy view of the data. The browser shows you a rendering, not the string. It shows you a glyph, not a code point. It shows you a shape that looks like a Japanese character, and you read it as correct because you trust your eyes more than your parser.

So the rule I keep coming back to is simple: when the text matters, verify the bytes and not the picture. Dump the code points. Look the word up. Do not trust the render.

It costs about thirty seconds and it is the difference between a bug that takes ten minutes and one that takes a week, because every person who looks at the screenshot will agree with you that the text is fine.