Decode &, ’, and ’ back to readable text, or encode text for safe embedding in HTML — with a choice of named or numeric entities, and a mode that only touches the characters that actually need escaping. Live, in your browser.
Encoding and decoding run entirely in your browser — nothing is uploaded, and the page works offline once loaded. Decoding uses the browser's own HTML parser, so the complete HTML5 named entity set is understood, not just a lookup table.
[ Ad slot — replace with AdSense / Ezoic code ]
When you need this
Entities show up as garbage in exactly the places you're trying to read or reuse text: CMS exports where every apostrophe is ’, RSS feeds and scraped pages full of &, translation files where café became café, and JSON APIs that double-escaped their HTML. Decoding turns those back into the characters they represent. Encoding goes the other way: you have text with <, &, or quotes in it and need to drop it into an HTML page, an XML file, or an attribute value without it being interpreted as markup — the classic injection-prevention escape.
The entities you'll actually meet, with all three spellings. Each row has its own anchor — link to #ent-nbsp, #ent-mdash, and so on to point a teammate at one row.
Char
Named
Decimal
Hex
Name
Named vs numeric — which should you write?
Browsers treat them identically, so the choice is about the humans and systems reading your markup. Named entities (—) are self-documenting in source code. Numeric references work for every one of Unicode's ~150,000 characters, while names exist for only about 2,200 — and crucially, numeric references also work in XML, where the only predefined names are &<>"'. Writing into an XML sitemap or RSS feed is a well-formedness error;   is fine. If your output might be consumed as XML, prefer numeric — that's why the encoder offers the preference.
[ Ad slot — replace with AdSense / Ezoic code ]
Frequently asked questions
Why does my text show &amp; — and how do I fix double-encoding?
Something encoded your text twice: the first pass turned & into &, then a second pass encoded that string's own ampersand, producing &amp;. It usually happens when two layers (a CMS and a template engine, or an API and a frontend) each escape defensively. To fix the text: decode here, and if the output still contains entities, decode again — each pass unwinds one layer. To fix the pipeline: escape exactly once, at the final output boundary, and store raw text everywhere else.
What's the difference between and a normal space?
is U+00A0, a no-break space: browsers won't wrap a line at it, and unlike runs of normal spaces it isn't collapsed by HTML whitespace rules. That makes it useful for keeping "10 km" together — and a menace when it sneaks into copied text, where it looks identical to a space but breaks string comparisons, searches, and diffs. When you decode text containing here, the output contains a real U+00A0 you cannot see. If a string mysteriously fails to match, check it with our invisible character detector, which highlights exactly these.
A few code points aren't valid characters: references to surrogate halves (�–�) and to � are errors per the HTML spec, and browsers substitute the replacement character �. This tool matches that behavior rather than producing invalid strings.
Is decoding untrusted text here safe?
Yes. Decoding happens in an inert, detached text-only context — markup in your input stays literal text and no scripts can run. And since nothing is uploaded, the untrusted text never leaves your machine either. One caution for what you do afterwards: decoded output is raw text, so if you insert it into a live page yourself, escape it again at that boundary.