Skip to content
TypeParser
All tools

HTML Entity Encoder

Encode and decode HTML entities.

beats string-functions.com edge: Named + decimal + hex output forms
decoded
encoded
direction style
paste text
Guide

About HTML Entity Encoder

Encode reserved characters as named, numeric (decimal), or hex entities. Decode handles all three forms cleanly. Optional non-ASCII-only encoding for compact output that still survives legacy charsets. Useful when embedding user content in HTML, when parsing scraped pages, and when sanitizing strings against XSS.

Why HTML entities still exist

HTML conflates text content with markup using a small set of reserved characters: <, >, &, ", '. Any of those in your data must be escaped or the parser will read it as part of the markup. Entity encoding is the bridge — < becomes &lt; and parses as the literal less-than character.

The original spec was ASCII; entities also let you embed any Unicode codepoint (&#128512; for 😀) when the page’s encoding could not represent it directly. Modern UTF-8 pages rarely need this, but the option survives for legacy systems.

Encoding modes

  • Named (&amp;, &lt;, &gt;) — readable, the default for hand-written HTML.
  • Decimal (&#38;, &#60;) — universal, every parser since 1995 reads it.
  • Hex (&#x26;, &#x3C;) — preferred by XML, used in some security configs.
  • Non-ASCII only — leave ASCII unchanged, encode only characters above 127. Compact, safe.

Common workflows

Sanitize user input for HTML output. Encode user-supplied strings before injecting into a template. Modern frameworks do this for you; for raw HTML generation, this tool is a backstop.

Decode scraped content. Pages scraped through HTTP clients arrive with entities intact. Decode here to get the plain text — useful for analysis or NLP preprocessing.

Verify your escaping. Paste suspected XSS input, see exactly what the encoder outputs. If <script> survives, your encoder is wrong.

Embed code snippets in HTML. Pasting <div> into an HTML page would render. Encoded &lt;div&gt; shows as text.

Why entities defeat XSS

XSS attacks rely on user content being interpreted as markup. If the user’s <script>alert(1)</script> becomes &lt;script&gt;alert(1)&lt;/script&gt; in the HTML, the browser sees text, not code. Escape consistently and the attack surface evaporates. Forget once and a single field becomes injectable. The mechanism is simple; discipline is everything.

Frequently asked questions

Which characters must be encoded?
Five always — & as &amp;, < as &lt;, > as &gt;, " as &quot;, ' as &#39;. Inside attribute values, quote handling is mandatory; in regular content, > and " are sometimes optional.
Named, decimal, or hex?
Named (&amp;) is most readable. Decimal (&#38;) is the most compatible — every parser since the 1990s reads it. Hex (&#x26;) is what XML output prefers. Pick by audience.
Is this enough to prevent XSS?
For text content, yes — escaping the five reserved characters blocks injection. For attributes, you also need to quote attribute values consistently and avoid building inline JavaScript or CSS via concatenation. Use a templating engine that escapes by default.
How do I encode emoji?
Emoji and other non-BMP characters encode as numeric entities with the full codepoint: &#128512; for 😀. Most modern parsers also accept the raw UTF-8 byte sequence directly.
Why does <code>&amp;nbsp;</code> matter?
Non-breaking space — keeps two words on the same line. Common in typography ("Mr. Smith" should not break). Your editor probably shows it identically to a regular space, which is what makes it a debugging headache.
Can I decode whole HTML pages?
Yes. Paste an entire page, decode mode strips entities to plain text. Useful when extracting content from scraped sources where entities slipped past a converter.

Related tools

Last updated: 2025-01-15