HTML Encoder / Decoder

Escaping a chunk of HTML so it shows up as text is the easy half, and honestly plenty of tools handle it fine. The decode side is where the free ones quietly give up, and it's usually the half that sent you searching in the first place. So that's what this one is built around. It goes both directions, entities out and entities back in, and all of it runs in your browser, so nothing you paste is uploaded, stored, or logged.

Picture the string that actually brings people here. Something dumped out of a CMS, an RSS feed, a scrape, or a crusty old database, and it's a wall of <p>, stray ’ curly quotes, and   filler you can barely read. Paste it, hit Decode, and it turns back into plain text as you type. No convert button to hunt for, no trip to a server, a private snippet just stays on your machine.

Encode and Decode share one toggle, and the Swap button feeds the result straight back into the input so you can flip a value without retyping it.

1. Pick Encode or Decode. Encode turns special characters into entities, Decode turns entities back into readable text. One toggle covers both.
2. Paste or type into the top box. The result updates in the box underneath on every keystroke.
3. Encoding and need pure ASCII out? Tick "Also encode all non-ASCII characters as numeric entities." For a normal UTF-8 page, leave it off.
4. Hit Copy result to grab the output. Or hit Swap to push it back into the input and flip the mode, which is how you verify a round trip or peel a second layer off double-escaped text.
5. Clear wipes both boxes for a fresh start.

Three things trip up a basic decoder, and this one handles all three.

First is hex. The same character can be written three ways: a named entity like  , a decimal one like  , and a hexadecimal one like  . A lot of quick decoders only ever learned the named set, or only decimal, so they hand ’ back to you untouched and you're left staring at a literal ’ where an apostrophe belongs. This one reads decimal and hex both, capital or lowercase X, and resolves them the same.

Second is anything past the basic plane. Emoji and a heap of symbols live at high code points, so a grinning face can arrive as 😀 or 😀. Decoders that assume every character fits in the low range mangle those into question marks or broken boxes. This tool decodes the full Unicode range, so both of those come back as an actual emoji.

Third, and this is the real day-to-day headache, is double-escaping. Text that passed through two systems often gets encoded twice, so a < ends up stored as < instead of <. One decode pass peels off exactly one layer, < becomes <, not <. That's expected, not a bug, the thing really was escaped twice. Decode once, hit Swap, decode again, and the second pass finishes it. Two clicks instead of copy, paste into a new box, repeat.

There's a quieter payoff to decoding here too. A lot of online decoders work by briefly turning your string into real page markup and reading the text back out, which is fine when you trust the input. It's the wrong move when the reason you're decoding is that you don't trust the string yet, because for a moment it becomes a live part of the page. Nothing you paste in here is ever rendered as markup. It reads every entity as plain text, straight through, so pasting a hostile <script> blob does nothing except show you, in plain characters, exactly what it says.

By default, encoding only touches the five characters that carry weight in HTML: &, <, >, ", and '. Those are the ones that break a page when they show up raw. The angle brackets open and close tags, the ampersand starts an entity, and the two quotes can end an attribute value early and spill the rest of your text into the tag as junk attributes. Escape them and your text renders as text. Everything else is left exactly as you typed it, spaces, line breaks, and ordinary letters all pass straight through, because none of them need changing.

One small choice is worth knowing. When it escapes an apostrophe, this tool writes ', not '. Both name the identical character, but ' came out of XML and older HTML parsers never recognized it, so it can quietly fail in some legacy client while ' decodes cleanly everywhere. It's a tiny correctness detail that basic escapers get wrong, and then it bites you six months later in an email that renders as gibberish. On the way in, the decoder still accepts ' too, so pasting either form works.

Under Encode there's one checkbox: also encode all non-ASCII characters as numeric entities. Leave it off and accented letters, currency signs, and emoji stay as themselves, which is the right call for any normal UTF-8 page. You want café to just be café in your source, not cluttered with codes.

Turn it on when the destination can't cope with anything above plain ASCII. Some legacy databases, a few email pipelines, and the odd stubborn old system still choke on raw multibyte characters, and for those, every character above code point 127 becomes a numeric entity. With it on, café comes out as café and an emoji as 😀, a pure-ASCII string that survives the trip in one piece. Most basic encoders don't offer this at all, they only ever touch the five, which leaves you converting accented letters by hand one at a time.