HTML Entity Encoder / Decoder

Escape and unescape HTML entities. Convert < > & " ' to named entities, optionally encode all non-ASCII characters, and decode named or numeric references back to text.

Escape text so it is safe inside HTML, or turn entities back into characters. Type in either box to convert in that direction. Minimal mode escapes only the five characters that matter for correctness; the extended mode also encodes every non-ASCII character for maximum compatibility.

Common entities

Character Named Numeric
& &amp; &#38;
< &lt; &#60;
> &gt; &#62;
" &quot; &#34;
' &#39; &#39;
\u{00A0} &nbsp; &#160;
\u{00A9} &copy; &#169;
\u{20AC} &euro; &#8364;

HTML entities and why escaping matters

The five characters that break HTML

An HTML parser reads < as the start of a tag and & as the start of an entity reference. If your content contains either, the parser stops treating it as text. Escaping replaces the character with a reference the parser resolves back to the original glyph without ever giving it structural meaning.

Only five characters genuinely need escaping in HTML:

  • & becomes &amp; — must be first, or you will double-escape everything else
  • < becomes &lt;
  • > becomes &gt;
  • " becomes &quot; — required inside double-quoted attribute values
  • ' becomes &#39; — required inside single-quoted attribute values

In element text you strictly only need & and <. The other three matter as soon as your text can land inside an attribute, and since you rarely control that at the point of escaping, escaping all five is the safe habit.

Named, decimal and hexadecimal references

The same character can be written three ways. A non-breaking space is &nbsp;, &#160; or &#xA0;. Named references are the most readable but the HTML5 list has about 2,200 entries and older parsers know far fewer, so obscure names are a portability risk. Numeric references work for any Unicode code point and are always safe. Every named reference in HTML5 requires the trailing semicolon; a handful of legacy names such as &amp still parse without it for backwards compatibility, but relying on that is a bug waiting to happen.

Escaping is not sanitising

Escaping is what stops cross-site scripting: if user input containing <script> is escaped to &lt;script&gt;, the browser renders the literal text and executes nothing. But escaping only works if it happens in the right context. HTML escaping is not enough inside a <script> block, inside a style attribute, or in a URL — each of those needs its own encoding. And escaping must be applied once, at output time. Escaping on input and again on output produces &amp;lt; and visible garbage.

When you need the extended mode

Escaping non-ASCII characters is not required by any modern specification. A UTF-8 document can contain é and directly, and that is usually the better choice: it is shorter, more readable and easier to search. Extended mode exists for the cases where the byte stream must survive a channel that mangles non-ASCII — some legacy email templates, older CMS fields, XML pipelines with an unclear declared encoding, or a build step that is stuck in Latin-1. If you control the encoding end to end, stay in minimal mode.

The non-breaking space trap

&nbsp; is U+00A0, a different character from the ordinary space U+0020. It prevents a line break and stops browsers collapsing runs of whitespace, which is why WYSIWYG editors emit it liberally. Because it looks identical, it silently breaks string comparisons, regular expressions written with \s in some engines, and CSV imports. If a value looks correct but refuses to match, check for a stray non-breaking space.

Open-source notice: implemented with plain string and code-point operations. No third-party library is used.

FAQs

Do I have to escape the greater-than sign?
Strictly no — a lone > in text is unambiguous and parses fine. It is escaped by convention because it costs nothing and avoids confusion in generated markup, particularly when the output is later processed by tools that are stricter than a browser.
Why must & be escaped first?
Because every other escape sequence starts with an ampersand. If you replaced < with &lt; before escaping &, the next pass would turn that ampersand into &amp; and you would end up with &amp;lt; on the page.
Is escaping enough to prevent XSS?
Only for HTML text and attribute contexts, and only when applied at output. Content injected into JavaScript, CSS or a URL needs the escaping rules of that language instead. Escaping is one layer, not a complete defence.
Named or numeric entities — which should I use?
Numeric references are universally supported and work for any code point. Named references are more readable for the handful everyone recognises. In practice use named for the five core characters and numeric for anything unusual.
Should I encode accented characters?
Not in a UTF-8 document, which is essentially all modern web content. Write them directly. Use extended mode only when something in your pipeline cannot be trusted to carry non-ASCII bytes intact.
What is the difference between &nbsp; and a normal space?
A non-breaking space is code point U+00A0. It looks the same but prevents line wrapping and is not collapsed with adjacent whitespace. It is also a distinct character for comparison purposes, which makes it a common source of subtle bugs.