HTML entity encoder

Convert special characters to safe HTML entities and back — for code samples, CMS pasting, and keeping user content from breaking your markup.

HTML Entity Encoder / Decoder

Convert special characters to safe HTML entities and back — for displaying code snippets, avoiding broken markup, and preventing injected HTML.

Result

Encoded HTML

Why HTML Entities Exist

Five characters have special meaning in HTML — &, <, >, " and ' — so writing them literally can break your markup or, worse, let user-submitted content inject live HTML into your page (the root of XSS attacks). Entities like &lt; tell the browser “display this character, don’t interpret it”.

You need encoding every time you show code examples on a page, put user input into HTML, or paste snippets into a CMS that renders markup. Decoding goes the other way — turning escaped text from an API or database back into readable characters. Every framework has helpers for this, but for one-off snippets a converter is faster than remembering which of the five characters you forgot.

The five characters that break HTML

HTML reserves a handful of characters for its own syntax, and writing them literally causes the browser to misinterpret your content. The critical five are & (starts an entity), < and > (delimit tags), and " and ' (delimit attribute values).

Encoding replaces each with a reference — &lt; for <, &amp; for & — which tells the browser to display the character rather than interpret it. Order matters when encoding by hand: escape the ampersand first, or you'll double-encode the entities you just created.

Why this is a security control, not a formatting one

Escaping output is the primary defence against cross-site scripting. If user-submitted text goes into your page unescaped, a comment containing a script tag becomes executable code running with your site's privileges — able to read cookies, hijack sessions and act as the logged-in user.

Escaping neutralises it entirely: the same input renders as harmless visible text. Modern frameworks escape by default, which is why XSS is rarer than it was — but every framework also has an escape hatch (dangerouslySetInnerHTML in React, v-html in Vue, innerHTML in vanilla JS). Those are where XSS lives today, so treat any use of them as needing justification.

Named versus numeric references

There are two forms. Named references like &copy; and &nbsp; are readable but limited to a defined list. Numeric references like &#169; or hexadecimal &#xA9; work for any Unicode character.

In practice, with UTF-8 encoding — which every modern site should declare — you can write most characters like é, — and © directly. Reserve entities for the five reserved characters, and for cases where the literal is invisible or ambiguous in source: &nbsp; for a non-breaking space is the classic example, since it looks identical to a normal space in your editor.

Decoding, and when you need it

Decoding runs the other way — turning &lt;div&gt; back into readable text. It comes up when an API returns pre-escaped content, when a database stores escaped strings, or when content has been double-encoded somewhere in a pipeline and displays as literal &amp;lt; on the page.

This tool decodes using the browser's own parser, so it handles named and numeric references correctly rather than relying on a lookup table that inevitably misses cases. One caution: never decode untrusted content and then insert it as HTML — that undoes the protection escaping provided in the first place.

Frequently asked questions

Which characters must be escaped in HTML?

Five: the ampersand, less-than, greater-than, double quote and apostrophe. Escape the ampersand first when doing it manually, or you will double-encode the entities you just created.

Does escaping HTML prevent XSS attacks?

Escaping output is the primary defence. Unescaped user content can inject executable scripts that read cookies and hijack sessions. Escaping renders the same input as harmless visible text — but it must be applied wherever untrusted content enters the page.

What is the difference between named and numeric entities?

Named entities like &copy; are readable but limited to a defined list. Numeric entities like &#169; work for any Unicode character. With UTF-8 you can usually write characters directly and reserve entities for the five reserved characters.

When should I use &nbsp;?

For a space that must not break across lines — between a number and its unit, or in a name that should stay together. Avoid using it for layout spacing; that is what CSS margin and padding are for.