HTML Entity Encoder and Decoder

How to Use This Tool

Paste text to make it safe to drop into HTML, or paste HTML to see the plain characters back. The counters underneath show whether the input was already encoded — the usual reason a page displays & to a reader.

Only five characters matter

Despite the size of the entity tables floating around, the working list is short:

& → & — always, because it starts every entity.
< → < — because it starts a tag.
> → > — not strictly required in text, and cheap insurance.
" → " — needed inside a double-quoted attribute.
' → ' — needed inside a single-quoted attribute.

Escape all five everywhere and you never have to think about which context you are in. It costs a few bytes and removes an entire category of bug.

The ampersand goes first

Encoding by hand fails in one predictable way. Replace < with < first, then replace & with &, and the second pass mangles what the first produced: < becomes &lt;, and the page displays < to the reader instead of a less-than sign.

The ampersand must be replaced before anything that introduces one. Decoding runs the opposite way — resolve & last, or you turn &lt; into a working tag, which is a real security bug rather than a cosmetic one.

Escaping all five characters everywhere avoids having to track which context you are in.

Entities are not for accented letters

Writing é for é or 中 for 中 is a habit from the days of single-byte encodings. Modern pages are UTF-8, and accented letters, CJK characters and emoji are all perfectly legal typed directly.

Encoding them anyway makes the file bigger, the source unreadable, and the text harder to search — é does not match a search for é. The "everything" option exists because you will occasionally meet a legacy system that needs it, not because it is a good default.

Escaping is not the same as sanitising

Escaping turns text into text: after it, <script> displays as characters and does nothing. That is the right answer when the content should never be markup.

If the content is meant to contain markup — a rich-text editor, user-submitted HTML — escaping is the wrong tool, because it would show the tags rather than apply them. That needs a sanitiser with an allowlist of permitted elements and attributes, which is a much harder problem and not one to solve with string replacement.

Frequently Asked Questions

Which characters need to be escaped in HTML?

Five in practice: & < > " and '. Only & and < are strictly required in text content, and a quote is required inside an attribute using that quote. Escaping all five everywhere costs a few bytes and removes the need to track context.

Why does my page show & instead of &?

The text was encoded twice. Something escaped the ampersand, then escaped the result again, turning & into &. Find the layer applying the second pass rather than decoding twice to compensate — a double decode breaks the moment the input arrives correctly encoded.

What order should I escape HTML characters in?

The ampersand first, always. Replace < before & and the < you just created becomes <, because the second pass escapes the ampersand the first pass introduced. Decoding runs the other way: resolve & last.

Do I need to escape accented characters as entities?

No. Modern pages are UTF-8, so é, 中 and emoji are all legal typed directly. Encoding them makes the file larger, the source unreadable, and the text unsearchable — é does not match a search for é.

Is escaping HTML enough to prevent XSS?

For text that should never be markup, yes — escaped text displays as characters and executes nothing. For content that is meant to contain markup, escaping is the wrong tool and you need a sanitiser with an allowlist of permitted elements and attributes.

Do I have to escape the greater-than sign?

Not strictly, in text content. It is escaped by convention because it costs one character, protects against a mis-parsed comment or CDATA section, and means one less rule to remember.

Escape the Ampersand First, or You Escape Your Own Escapes

How the calculation works