HTML Entity Encoder

HTML Entity Encoder

Encode and decode HTML entities online. Convert special characters like <, >, &, quotes to HTML entities. Free HTML escape/unescape tool

HTML entity encoding is the boring-but-load-bearing function at the bottom of every XSS prevention story. Encode < as &lt; and an attacker cannot close your tag. The interesting part is which characters you actually need to encode — the OWASP recommendation differs between text-context, attribute-context, JS-context, and URL-context, and getting it wrong is a security bug. This encoder/decoder handles all four contexts, supports named entities (&amp;) and numeric (&#38; / &#x26;), and shows you which form is safest for your situation.

Where you actually need entity encoding

  • HTML text context (<p>Hello, user!</p>) — encode &, <, >. Most XSS-prevention articles stop here.
  • HTML attribute context (<img alt="..."/>) — encode &, ", '. Unquoted attributes need much more aggressive encoding; always quote attributes.
  • JavaScript context (<script>var x = "...";</script>) — entity-encoding does NOT protect you here. The browser HTML-decodes the script body before passing to the JS parser; an attacker can break out with \u escapes or unicode literals. Use JS-string escaping (JSON.stringify) instead.
  • URL context (<a href="...">) — encode special URL characters with percent-encoding (%3C for <), not HTML entities. Then HTML-encode the result in the attribute.
  • CSS context (<style>color: ...</style>) — escape with backslash-hex (\3C for <). Entity-encoding does not work — CSS does not HTML-decode.

Working example: the XSS attack surface

Input

User-supplied input: <script>alert(1)</script>
Inserted into: <div data-comment="...">

Output

Wrong (unescaped):
  <div data-comment="<script>alert(1)</script>">
  Renders fine. Browser does NOT execute the inner <script> here.
  But: change to <div title="...">"></div><script>alert(1)</script><div title=""> and you escape the attribute.

Correct (HTML attribute encoding):
  <div data-comment="&lt;script&gt;alert(1)&lt;/script&gt;">
  Inner content is literal text. No way to break out.

The minimum safe attribute encoding is: & → &amp;, " → &quot; (or &#34;), ' → &#39; (NOT &apos; — invalid in HTML 4, only valid HTML5+). Encode aggressively: when in doubt, also encode <, >, /, =, and the backtick.

Named vs numeric entities

  • Named — &amp;, &lt;, &gt;, &quot;, &nbsp;. Five characters everyone uses. HTML5 defines ~250 named entities (&copy;, &reg;, &mdash;, &trade;) all of which work in modern browsers.
  • Numeric decimal — &#38; for &. Universal, works in every browser since the 1990s. Verbose for common characters.
  • Numeric hex — &#x26; for &. Same coverage as decimal, common in security-tool output, less common in hand-written HTML.
  • Named entity caveat — &apos; for ' was XML/HTML5 only. In HTML 4 documents, &apos; renders as literal "&apos;". Use &#39; for cross-version safety.

When to reach for this tool

  • You are testing whether a CMS / forum / commenting system is properly escaping output, and need a payload that exercises the encoding logic.
  • You inherited a template that string-concatenates HTML and want to confirm which characters need encoding to make a specific field XSS-safe.
  • You are debugging "the page shows &amp;amp; instead of &amp;" — double-encoding bug, your data was already encoded once when the renderer encoded it again.
  • You need to embed a code sample with literal HTML in an HTML document and want to convert <tags> to entity form quickly.

What this tool will not do

  • It will not make your application XSS-proof. Entity encoding is one piece — output context awareness, Content Security Policy, and proper templating engine usage (auto-escaping by default) are the rest.
  • It will not handle JavaScript-string escaping. Use JSON.stringify() on the server side or a dedicated JS-escape function. Entity-encoding into a JS context creates a different class of bug.
  • It will not convert URLs. Percent-encoding (for URLs) and entity-encoding (for HTML) are separate; running URL strings through HTML encoding is mostly harmless but does not protect against URL-injection.

Input and output stay in your browser. Useful when handling payloads or production HTML samples that you do not want to upload to a third-party encoder.

Frequently asked questions

Do I need to encode > in HTML text?

Per the HTML5 spec, no — the > character is only special at the start of a tag. In practice, encode it anyway (&gt;) for safety against parser quirks and for consistency. Encoding harmless characters is cheap; missing one needed character is a vulnerability.

Is &apos; or &#39; the right encoding for a single quote?

&#39; is universally safe. &apos; is HTML5+ and XML — valid for new documents, can render as literal text on HTML 4 documents. Use the numeric form unless you control the entire pipeline.

Why does my encoded text show as the raw entity (&lt;) instead of the character?

Either the encoding is applied twice (the renderer already decodes; encoding before saving and then again at output produces &amp;lt; → renders as &lt;) or the renderer is set to "do not decode entities" (e.g., textContent in JS vs innerHTML).

Can I just use a strict CSP and skip entity encoding?

No. CSP blocks inline scripts and reduces the impact of XSS, but content-injection that does not run JS (DOM-clobbering, form action injection, link href poisoning) still works. Defense-in-depth: encode AND CSP.

Is there a way to encode only the dangerous characters?

Yes — most libraries (Python's html.escape, JS escape-html) encode only &, <, >, ", '. Heavier encoders also wrap non-ASCII as numeric entities for legacy compatibility. For modern UTF-8 documents, encoding non-ASCII is unnecessary and bloats the HTML.

How is this different from URL-encoding?

Different alphabets, different uses. URL-encoding (percent-encoding) is for URIs: spaces become %20, < becomes %3C. HTML entity encoding is for HTML: spaces stay as spaces, < becomes &lt;. They are not interchangeable — using one where the other belongs creates injection bugs.

Related tools

Last updated · E-Utils editorial team