HTML Entity Decoder to Turn Codes Back Into Characters

Sooner or later, anyone who moves text between systems meets a paragraph that looks like this: Tom &amp; Jerry, caf&#233;, 5 &lt; 10. Nothing is actually wrong with the words. They have been written using HTML entities, the escape codes that let characters like &, < and the copyright symbol travel safely through web pages and data files. This HTML entity decoder converts those codes back into the plain characters they represent, turning an unreadable export or copied page source back into text you can read, edit and reuse.

What HTML Entities Are, in Plain Terms

An HTML entity is a short code, beginning with an ampersand and ending with a semicolon, that stands for a single character. They come in three forms. Named entities use a memorable word, such as &copy; for the copyright symbol and &nbsp; for a non breaking space. Decimal entities use the character's number, like &#169; for the same symbol, and hexadecimal entities write that number in base 16, like &#xA9;. Entities exist because some characters are reserved: in HTML source, a bare < starts a tag and a bare & starts an entity, so to display those characters as text they must themselves be encoded. Browsers decode entities automatically when rendering a page, which is why you see the symbol on screen while the source underneath says &copy;. The MDN glossary entry on entities explains the mechanism from the standards side.

How to Decode HTML Entities

1. Copy the encoded text from wherever you found it: page source, an export, a feed or a document.
2. Paste it into the decoder's input area.
3. Click Decode HTML Entities to run the conversion.
4. Read the result in the output: entities are replaced by their real characters throughout.
5. Click Copy to take the decoded text away for your editing, migration or analysis work.
6. If traces of encoding remain, see the note on double encoding below before assuming something is broken.

Where Encoded Text Turns Up

The commonest source is copied page source: you view source to grab a headline or a block of text and bring home the entities with it. Data exports are another, because RSS feeds, XML and JSON dumps and CMS migration files routinely carry entity encoded content, and the receiving system does not always decode it for display, which is how &amp; ends up printed on live pages. Scraped content, email templates and text pulled from databases can arrive the same way. Decoding is the clean up step in all of these workflows. The reverse job belongs to our HTML entity encode tool, and characters encoded for URLs rather than HTML belong to the URL decoder.

Double Encoding and Other Traps

Sometimes text has been encoded twice, once when it was stored and once when it was exported, leaving forms like &amp;lt;, which decodes in one pass only as far as &lt;. If your decoded output still contains visible entities, run it through the decoder once more; each pass peels off one layer. The opposite caution matters too: decoded text contains live characters again. If the decoded content includes HTML tags, pasting it into a web page makes those tags real markup rather than displayed text, which is desirable only when that is genuinely your intention. Decode for reading and editing; for display on a page, text should normally go back out encoded.

Frequently Asked Questions

Why does my page show &amp; to visitors instead of an ampersand?

That is the signature of double encoding: the text was entity encoded, and then encoded again, so the browser faithfully displays the literal characters of the first encoding. The fix at the content level is to decode once, which is what this tool does, and store or publish the singly encoded or plain version so the ampersand renders as itself.

What is the difference between named and numeric entities?

Only the notation. &copy;, &#169; and &#xA9; all produce the same copyright character. Named entities are easier for humans to read but exist only for a defined set of common characters, while numeric forms can express any character in Unicode, including ones that have no name. A decoder handles all three forms equally.

Is it safe to decode any text I find?

Decoding itself is a harmless text transformation: it changes codes into characters on your screen. The safety question is about what you do next. Decoded text may contain live HTML or script, so do not paste decoded material from untrusted sources straight into your website as markup. Treat it as text, review it, and encode it again before displaying it.

Why is some encoding still visible after one decode?

Because the text was encoded more than once before it reached you. Each decode pass removes exactly one layer, so doubly encoded text needs two passes, revealing the singly encoded form first and the true characters on the second. Check the output after each pass so you stop at plain text.

Will decoding fix garbled characters like caf&#233;?

Yes. caf&#233; is the word café with its accented letter written as a decimal entity. Decoding turns the code back into the character it stands for, restoring the readable word. The same applies to entities standing for punctuation, currency signs and symbols of every kind.

How is this different from URL decoding?

They undo different alphabets. HTML entities encode characters for documents, using forms like &copy;. URL encoding uses percent codes, like %20 for a space, to keep addresses valid. Text from a web page usually wants this decoder; text copied out of an address bar wants the URL decoder.

Final Thoughts on Using the HTML Entity Decode

The HTML entity decoder turns escape coded text back into the characters it was always meant to show, whether the codes came from page source, a feed or a database export. Paste, decode, copy, and remember the one habit that prevents most confusion: decode once for each layer of encoding, and encode again before the text goes back on display.