Text Runs locally Ready to use Built-in examples No tracking

HTML Entity Encoder

Encode text by escaping the five essential characters (& < > " ') or by turning all non-ASCII into numeric entities; decode named and numeric entities back to plain text with lossless fallback.

Five characters mean something special in HTML: the ampersand starts an entity, the angle brackets open and close a tag, and quotes wrap attributes. Appearing in ordinary prose they must be escaped, or the page at best renders wrongly and at worst runs an injected script. The "necessary characters only" mode does exactly that minimal escape — those five and nothing else — which is what belongs on comment or form content before it is stored.

The "all non-ASCII" mode goes further, turning CJK characters, symbols and emoji into numeric entities such as &#x4F60;, which survive any encoding environment (old systems, email, JSON) at the cost of a larger payload. Emoji are converted by codepoint as a whole rather than split into half a surrogate pair. Decoding handles named entities and decimal or hexadecimal numeric ones, and leaves an entity it does not recognise in place rather than dropping the content.

—
—
—
—

How to use

  1. Paste the text or the HTML source.
  2. Choose the encoding mode: necessary characters only, or all non-ASCII.
  3. Choose the decoding direction to turn entities back into characters.
  4. Read the result; unknown entities are preserved rather than discarded.

How it works

The five-character minimal escape

The "necessary characters only" mode handles exactly the five with special meaning: & → &amp;, < → &lt;, > → &gt;, " → &quot;, ' → &apos;. This is the minimal safe set for text contexts — run body text, comments or form values through it before storing or echoing, and the tag-injection entry point closes; Chinese and everything else passes through unchanged at almost no size cost.

Numeric entities and encoding immunity

The "all non-ASCII" mode converts every non-ASCII character beyond the five into hexadecimal numeric entities: the Chinese character 你 becomes &#x4F60;, the emoji 😀 becomes &#x1F600;, and ™ prefers the named &trade;. Numeric entities are pure ASCII, so they survive any encoding environment (legacy APIs, ASCII-only channels, email) without mojibake — at the cost of length: one Chinese character grows from 3 bytes to 8 characters.

Decode rules and round-trip fidelity

Decoding follows the HTML standard: named entities look up a table (&amp; → &, &copy; → ©), numeric entities accept both decimal (&#20320;) and hex (&#x4F60;), and supplementary-plane code points are restored whole rather than split into surrogates. Unrecognized entity names pass through untouched — fewer conversions beat lost content — and the same rule keeps encode → decode round trips faithful.

Code example

JavaScript Let the DOM do the authoritative encoding 

// the browser owns the complete entity table: hand it to a textarea/textContent
const encode = (s) => {
  const el = document.createElement('div');
  el.textContent = s;                  // put it in as plain text first
  return el.innerHTML;                 // reading back escapes < > & as needed
};
encode('<a href="x">text</a> & more');  // '&lt;a href="x"&gt;text&lt;/a&gt; &amp; more'

// the reverse: assign the entity string as HTML and read textContent back
const decode = (s) => {
  const el = document.createElement('textarea');
  el.innerHTML = s;
  return el.value;
};
decode('&lt;b&gt;&#x4E2D;&yen;');        // '<b>' + U+4E2D + currency sign

// innerHTML decodes every entity (named ones like &nbsp; too) — why this beats a hand-rolled regex

Python html.escape / html.unescape 

import html

html.escape('<a href="x">text</a> & more')
# '&lt;a href=&quot;x&quot;&gt;text&lt;/a&gt; &amp; more'
html.escape('"quotes \'and\' more"', quote=True)     # quote=True also escapes quotes

html.unescape('&lt;b&gt;&#x4E2D;&yen;&nbsp;')
# '<b>' + U+4E2D + currency sign + '\xa0'

# escape only < > & (leave quotes alone): html.escape(s, quote=False)

FAQ

Why must < and & be escaped?

< starts a tag as far as the browser is concerned — the text after it may parse as an element or even a script; & begins entities and would collide with real ones like &amp;. Escaping these five characters before storing or echoing body text is the most basic anti-injection step.

Necessary-only or all non-ASCII — which mode?

Web body text and databases: the former — only five characters escaped, Chinese readable, size small. Uncertain-encoding environments (legacy APIs, mail headers, ASCII-only channels): the latter — Chinese and emoji all become numeric entities and can't corrupt, at several times the length.

Why isn't a space converted to &nbsp;?

&nbsp; decodes to a non-breaking space (U+00A0), not a normal space (U+0020) — converting would change the text's meaning and break the encode-decode round trip. Spaces stay as-is to guarantee fidelity.

Will emoji be mangled by entity encoding?

No. Emoji are supplementary-plane characters, converted by complete code point: 😀 becomes &#x1F600;, not two orphaned surrogates, and decodes back intact.

Are unknown entities deleted?

No. Unknown names (like &nope;) pass through untouched while the rest decodes normally — fewer conversions beat lost content.

How much does encoding inflate the size?

"Necessary only" barely changes (just the & < > quotes present); under "all non-ASCII" a Chinese character grows from 3 bytes to 8 characters (&#x4F60;) and an emoji to 10. Choose by how encoding-reliable the destination is.

Can it process a whole HTML page?

Yes. Paste the source: choose "decode" to turn &lt;div&gt;-style entities back into readable text, or "encode" to escape the whole thing into safe display text where tags appear as &lt;div&gt; instead of executing.