HTML Entities in JSON and API Data: Why Your Text Shows & and How to Fix It

You build a page that pulls a product name from an API, and somewhere in the middle of the description it prints & at the reader. Not the ampersand — the literal six characters. You check the JSON, and sure enough, the API sent you a string that was already HTML-encoded, and your frontend dutifully rendered the escape sequence instead of the symbol. This is one of the most common text-corruption bugs on the web, and it's completely fixable once you understand which layer owns the encoding.

Two Different Escapes, Two Different Jobs

JSON and HTML both escape special characters, but for opposite reasons. JSON escapes quotes and backslashes with backslashes so the data survives parsing — & style. HTML escapes &, <, and > as entities so the browser doesn't misinterpret them as markup. The corruption starts when someone double-encodes: a backend encodes a field as HTML, stuffs it into JSON, and the frontend — which already treats JSON values as safe text — prints the raw entity. The result is a string that's escaped exactly once too many.

The counter-intuitive part: the fix is usually at the source, not the display. If your API controls the data, stop encoding it as HTML in the first place; JSON handles its own escaping. If you're stuck with legacy data, decode the entity after you receive it — run the value through an HTML entity decoder once, before it hits your component. Decode at the boundary, and you never have to patch the renderer.

Where the Leaks Actually Show Up

This bug hides in the places you'd least expect. A CMS that stores rich text as encoded HTML, then serves it through an API, is a classic source. E-commerce titles with & in the brand name, blog excerpts with curly quotes stored as ”, user-generated content that passed through a sanitizer — all of them arrive already encoded. The tell is that some fields render fine and others don't: the ones that look broken were encoded twice, the ones that look fine were encoded once or not at all.

When you're debugging, check the raw value before you blame the frontend. If the field literally contains &, that's a double encode — decode once. If it contains a bare & in the JSON text, that's an un-encoded source, and the renderer should handle it. A quick way to tell which layer is wrong is to paste the value into a markdown preview and watch how it renders as markup. And if you're dealing with URLs that got entity-encoded along the way, run them through a URL encoder/decoder to normalize them back to a usable form.

Set One Rule and Stop Fighting It

The whole class of bugs disappears with one rule: HTML-encode at the moment you write HTML, and never store the encoded form. Store clean data, escape at the boundary, and let the frontend render what it receives. We covered the display side of this in our guide to special characters and cross-platform encoding; the JSON leak is the same principle traveling backward. If you're already dealing with a corrupted feed and need to see what you're actually working with, the HTML entity tool will decode any batch of text in one pass — no regex, no guesswork.