Articles on a client's website started coming out wrong. Instead of wrapping, the text ran off the right edge in one long line. You had to scroll sideways to read a paragraph, and on a phone it was unusable.
Only some articles, and always the same way.
The obvious suspect was an invisible character. Text pasted from Word or a PDF picks up all kinds of things you can't see, and some of them can glue a paragraph together so the browser won't break the line. So that's what we looked for, repeatedly, on and off for weeks between other jobs.
We never found it, because it wasn't in the text.
The clue we kept ignoring
Retyping an article fixed it. Editing and re-saving didn't. Typing the words again by hand did.
That should have been the answer on day one. If the same words typed a second time behave differently, the problem lives in whatever handled them the first time.
The editor was doing it
The site uses a rich text editor, the box with the bold and italic buttons. When you hit save, the editor converts what's on screen into HTML to store in the database, and it has a function for exactly that job.
That function was writing every space as a non-breaking space.
A non-breaking space looks identical to a normal one. It carries one extra instruction: don't break the line here. It exists for things like "10 kg" or "Dr. Smith," where a line break in the middle reads badly.
Put one between every pair of words in a paragraph, and you've told the browser the whole paragraph is one unbreakable word. The browser does what it's told and the text runs off the page.
Why it took weeks
It looked normal on screen. In the editor, the spaces displayed as spaces. Nothing was highlighted or flagged.
It kept coming back. Every save reapplied it, so "I fixed that one" was always temporary, which made it look like the mystery character was creeping back in from somewhere.
And we were inspecting the wrong thing. We kept reading the article, but the damage happened in the step between the article and the database. The only place you could actually see it was the raw HTML stored in the database, which is the last thing anyone opens when a page just looks wrong.
Where the fix goes
The fix is small: on the way out of the editor, convert those non-breaking spaces back to ordinary spaces before anything is stored.
Where you put it matters more than the code. It belongs at the boundary, the single place where editor content becomes stored content. If you fix it in the template that displays articles, the bad data keeps piling up in the database and surfaces the first time something else reads it. If you fix it with a cleanup script, you'll be running that script after every save forever.
Two habits I took away from this one. When retyping fixes something, suspect the tool before the text, because that points straight at whatever sits between you and the saved copy. We had that clue in week one and read it as "this text is cursed." And when a page looks wrong, go look at the raw value in the database. Any tool that converts your content from one format to another can change it, and the rendered page won't tell you what changed.