HTML Entity Encoder/Decoder Online Free

Encode special characters to HTML entities or decode HTML entities back to text. Handles named and numeric entities. 100% client side.

HTML Entity Reference

HTML entities represent special characters that have meaning in HTML. Common entities:

&   → &    (ampersand)
&lt;    → <    (less than)
&gt;    → >    (greater than)
&quot;  → "    (double quote)
&apos;  → '    (apostrophe)
&nbsp;  →      (non-breaking space)
&copy;  → ©    (copyright)
&mdash; → -    (em dash)

Related Tools

HTML Entity Encoding: Why < Still Matters

HTML entity encoding looks archaic — &lt; for <, &amp; for &, &quot; for ". But getting this right is the difference between a safe page and one that cross-site-scripts every visitor. Every framework's "safe by default" claim ultimately reduces to: it entity-encodes user data before inserting it into the DOM.

The five characters that actually matter

  • & → &amp;
  • < → &lt;
  • > → &gt;
  • " → &quot;
  • ' → &#39; (or &apos;, but #39 has wider support)

Encode all five whenever you insert untrusted data into HTML. That's it for the body of an element. Attribute values need additional rules.

Where to encode (and where it gets harder)

  • HTML body: the five-character set above.
  • HTML attributes: same five, but make sure the attribute value is double-quoted. Inside onclick="...", you also need JavaScript-escaping — entity encoding alone is not enough.
  • JavaScript context: <script>var x = "USER_DATA";</script> needs JS-string escaping (\", \\, \/), not HTML entities.
  • URL context: encodeURIComponent, not entity encoding.
  • CSS context: CSS hex escapes, not entities.

One context, one encoding. Mixing them is how XSS sneaks through "encoded" output.

Numeric entities and unusual characters

Beyond the named entities, every Unicode codepoint has a numeric entity: &#8364; for €, &#x2603; for ☃. UTF-8 has made numeric entities mostly unnecessary — just serve UTF-8 and use the literal character. The exception: when you can't trust the surrounding charset (email HTML, some legacy CMS exports), numeric entities give you a portable encoding.

Common mistakes

  • Not escaping ampersand. ?a=1&b=2 in an href is technically invalid HTML and breaks some parsers. Encode as &amp;.
  • Double-encoding. Encoding twice produces &amp;amp; in the rendered output. Track which strings are raw vs encoded.
  • Trusting frameworks blindly. Most frameworks escape body content automatically but not attributes or v-html/dangerouslySetInnerHTML equivalents.
  • Stripping entities. Some "sanitizers" remove all entities — including legitimate ones in user-generated content. Encode, don't strip.

For deeper XSS context, see our API security playbook.

Frequently Asked Questions

Why do I need to encode & even when not in an attribute?

A bare & followed by certain letters can be interpreted as an entity (e.g. &copy or &reg). Always encoding it removes ambiguity.

Are entities case-sensitive?

Named entities like &lt; are. Numeric entities (&#60;) and hex entities (&#x3C;) are not.

Should I HTML-encode user input or sanitize it?

Both. Encode on output as the last step before insertion. Sanitize early if you need to allow some HTML (use a library like DOMPurify).

Is entity encoding enough to prevent XSS?

In HTML body context, yes. In attributes, JavaScript, URLs, or CSS context, you need additional context-aware encoding plus a Content Security Policy as defense-in-depth.