What does an HTML encoder do?
An HTML encoder replaces the characters that would otherwise be read as markup with character references that render as the characters themselves. An ampersand starts a reference, a less-than sign starts a tag, and a quote can end an attribute value. Escaping those turns a string into text that a browser displays rather than acts on.
The decoding direction is the same table read backwards, and it is what you need when reading HTML source, an email, or an exported database field full of references. The tool handles numeric references in both bases and the common named set, and it leaves a name it does not recognise as written rather than guessing at it.
The interesting part is how much to escape, which depends on where the text is going. Only two characters are strictly required — the ampersand and the less-than sign — for text between tags. Inside a double-quoted attribute a quote matters too. Inside a script or an event handler the honest answer is not to interpolate unescaped text at all, but the extra set exists for when you must. The options here make that distinction explicit instead of hiding it behind a single button.
How to encode or decode HTML
- Choose a direction: encode to entities, or decode references back to text.
- Paste the text or markup into the box. The result appears as you type.
- When encoding, pick how much to escape. The structural characters are on by default; add quotes if the text may land in an attribute, and the extra characters for a script context.
- Turn on the ASCII-only option if the output has to survive an encoding mismatch, and remember that it makes the source harder to read on a page that is already UTF-8.
- Copy the result, or press Use this as the input to run the other direction on the output and check that it round-trips.
- When decoding, watch for names that were left alone. Those are outside the table the tool knows, so nothing was guessed at.
HTML Encoder / Decoder limits and rules
| Item | Limit |
|---|---|
| Encode set | & < > always optional; " and ' for attributes; / ` = ! ( ) $ @ as extras |
| Named decoding | amp, lt, gt, quot, apos, nbsp, copy, reg, hellip, mdash, ndash and the typographic quotes |
| Numeric decoding | Decimal A and hexadecimal A refers, including astral code points |
| Non-ASCII option | Every character outside ASCII becomes a numeric reference |
| Unknown names | Left exactly as written, rather than guessed at |
| Not done | Character-set detection, tag sanitising or full HTML parsing |
| Newlines | Preserved as typed — no wrapping or normalisation |
| Encoding assumed | UTF-8, which is what almost every page is served as today |
When to use it
- Posting a code snippet to a comment box that renders HTML, so the tags show instead of running.
- Escaping text that goes into an attribute value in a template.
- Reading a scraped or exported field full of & and ’ as normal text.
- Producing a version of a string that survives a paste through a system with an unclear character encoding.
- Checking what a page's source meant after a mojibake episode turned apostrophes into a sequence of characters.
Is it private?
Both directions run in JavaScript in this page. The text is never uploaded, stored or logged, so pasting an internal snippet or an exported database row is as private as not pasting it at all.
Frequently asked questions
Strictly, two: the ampersand, because it begins a character reference, and the less-than sign, because it begins a tag. Escaping those two is enough to make text render as text. The greater-than sign does not need it — nothing begins with it — but escaping it is conventional and harmless. Quotes matter only when the text goes inside an attribute, and then only the quote character that delimits it. Everything else in the extra set is about contexts beyond plain body text.
It is safe to do so and it costs nothing but readability. Escaping a double quote as " renders identically to a literal quote in body text, so there is no downside except that the source becomes slightly noisier. Escaping quote characters is the pragmatic choice when the same string might be interpolated into different contexts, because it removes the need to know in advance whether the text will end up between tags or inside an attribute. That is why the option is on by default here.
Nothing in the result: both render as an ampersand. The first is a named reference, a human-readable alias the HTML standard defines for a set of common characters, and the second is the numeric reference giving the code point in decimal. Named references are shorter and easier to read, but the set of names is finite, while numeric references exist for every character in Unicode. When a character has no name, or when you need to be certain a parser accepts it, use the numeric form.
Because it only decodes names it knows. There are well over two thousand named references in the HTML standard, and a table that guessed at an unfamiliar one, or that decoded something like ∉ by matching the ¬ prefix first, would corrupt text silently. The tool decodes the common set and leaves everything else exactly as it found it, so an unknown name is visible rather than wrong. If you frequently work with a name outside the set, the numeric reference always decodes correctly.
Almost never. It was a real fix in the era of pages served as ISO-8859-1 or with a missing charset declaration, when escaping every accented character as a numeric reference guaranteed it would render whatever the server said the encoding was. On a page served as UTF-8, which is effectively every page today, the characters travel through unchanged and the escaping only makes the markup harder to read and edit. Treat the ASCII-only option as a compatibility lever for a specific problem, not as a default.
No, and nothing that just converts characters should be relied on for that. Escaping is one part of a defence, and the rules differ per context: text between tags, an attribute value, a URL, a style block and a script block all need different treatment, and a scheme like javascript: in an href needs validation rather than escaping. Use a templating engine that escapes by default and a sanitiser that parses HTML when you must accept markup from a user, and treat this tool as a way to understand and inspect the conversion rather than as a security control.
Related tools
Written and maintained by Md. Nur Hossain Repon.