HTML Entity Encoder / Decoder

Escape and unescape HTML entities so markup renders as text

Runs entirely in your browser. Your data never leaves this device.

Input
Output

How to use it

  1. Paste text or markup into the input panel.
  2. Choose Encode to turn characters into entities, or Decode to turn entities back into characters.
  3. Switch between named and numeric output if you need a specific form.

Why entities exist

HTML has to solve a problem every markup language faces: some characters mean something to the parser. < starts a tag, & starts an entity reference. If your content contains those characters literally, the parser cannot tell content from markup. Writing 5 < 10 in a page risks the browser treating < 10 as the start of a malformed tag.

Entities are the escape hatch. &lt; says "a literal less-than sign goes here" without ever giving the parser a < to act on. The core set is small: &amp; for &, &lt; for <, &gt; for >, &quot; for ", and &#39; for '.

The & case deserves attention because it is self-referential and the source of a lot of confusion. Since & starts an entity, a literal ampersand must itself be escaped — otherwise &copy in the middle of a sentence renders as ©. And because & is escaped first, encoding must always begin with it, or you end up double-escaping everything that follows.

The historical layer

HTML5 defines well over two thousand named entities — &nbsp;, &copy;, &mdash;, &hellip;, &aacute; and a long tail of mathematical and typographic symbols. Almost all of them are historical. They exist because early web pages were served in single-byte encodings such as ISO-8859-1, where a character like simply could not be represented in the source file. Entities were the only way to get it onto the page.

With UTF-8 that constraint is gone. A modern page can contain , , ş and 😀 directly, and doing so keeps the source readable. The five markup-significant characters are the only ones you genuinely need to escape; everything else is a stylistic decision, or a requirement imposed by a specific pipeline such as an XML feed or an email template.

Escaping is context-dependent

The most common mistake is treating "escape HTML" as one operation. It is not — the correct escaping depends on where the value lands.

  • HTML text content — escape &, <, >.
  • Attribute value — also escape the delimiting quote, and always quote your attributes. Unquoted attributes can be broken out of with a space.
  • Inside a <script> block — HTML escaping is wrong and dangerous. You need JavaScript string escaping, plus care with the literal sequence </script>.
  • In a URL — you need percent-encoding, not entities.

This is why hand-rolled sanitising tends to fail. Template engines like Razor, JSX and Jinja apply contextual encoding automatically, and reaching past them (@Html.Raw, dangerouslySetInnerHTML) is where injection bugs get introduced. Use this tool for inspecting and converting content — not as a security control in a rendering pipeline.

Frequently asked questions

Which characters actually need escaping?

In text content, `&`, `<` and `>`. Inside an attribute value you also need the quote character that delimits it — `"` or `'`. Everything else is optional and mostly a legacy of pre-UTF-8 encodings.

Named or numeric entities — which should I use?

Named (`&amp;`) is more readable; numeric (`&#38;` or `&#x26;`) works even where the name is not defined, which matters in XML. For HTML documents served as UTF-8 the choice is cosmetic.

Does escaping HTML protect me from XSS?

Only in the context it was designed for. Escaping is context-dependent — HTML text, HTML attributes, JavaScript and URLs each need different escaping. Use your framework's contextual output encoding rather than escaping by hand.

Why does `&nbsp;` behave differently from a space?

It is a non-breaking space (U+00A0). Browsers do not collapse it and will not wrap a line at it, which is why copied text from a rendered page sometimes fails string comparisons.

Should I escape Turkish or accented characters?

Not if your page is UTF-8, which it should be. `ş` and `é` are perfectly valid characters — escaping them just makes the source harder to read.

Related tools

browse category →

Last updated: