HTML Entities Encode / Decode

Encodes and decodes HTML's reserved characters (& < > " ') to display text safely.

This version converts HTML's five reserved characters (& < > " '). Converting entities like &eacute; and &copy; may be added in a future version.

What are HTML entities

HTML entities (or character references) represent, inside an HTML document, characters that have special meaning in the language itself — like < > & (which delimit tags and attributes) — without risking the browser interpreting them as markup. They come in three equivalent forms: named (&amp;, &copy;), decimal (&#38;), and hexadecimal (&#x26;) — all three represent the exact same character.

When to use it

Whenever free text — untrusted, typed by someone, coming from an API — needs to be inserted into the body of an HTML document without characters like < or & being interpreted as the start of a tag or entity. Typical cases: displaying a user comment, a name containing "&" (e.g., "Tom & Jerry"), a code snippet inside <pre>/<code>, or any value headed for a template without automatic escaping. It isn't necessary for text that already goes through a framework with automatic escaping (React, Vue, Angular) — the framework already does this when rendering.

Named vs. numeric entity

A named entity (&amp;, &copy;, &euro;) is more readable, but depends on the browser recognizing that specific name — HTML5 defines an extensive, but finite, list. A numeric reference (&#38; decimal, &#x26; hexadecimal) uses the character's Unicode code point directly and works for any existing character, named or not. This tool's Decode recognizes all three forms, delegating to the entity table already built into the browser engine.

Difference from URL Encoding

Both techniques solve the same kind of problem — safely representing a special character inside a format that would otherwise give it a different meaning — but in different contexts. URL Encoding (percent-encoding, %XX) protects characters inside a URL; HTML Entity Encoding protects characters inside the body of an HTML document. Pasting an already URL-encoded value into an HTML context (or the reverse) doesn't work — they're independent escape tables with no relationship to each other.

Where you'll run into it day to day

In any template engine without automatic escaping, in RSS/Atom feeds, in HTML emails, in CMSs that store content as raw HTML, and anywhere user text needs to coexist with real markup in the same document. Full example: a comment "5 > 3 && 2 < 4" saved without conversion would break the page's HTML; saved as "5 &gt; 3 &amp;&amp; 2 &lt; 4", it displays correctly as text.

Frequently asked questions

Double-encoding happens when the "&" produced by a substitution (e.g., "<" → "&lt;") gets escaped again, turning into "&amp;lt;" — an incorrect result. This tool converts everything in a single regex pass over the original text: every reserved character is decided against the input, never against an already-substituted result, so this problem can't occur, regardless of any internal implementation ordering.

&#39; (numeric) is valid in HTML4, HTML5, and XML — the convention used by most reference libraries (lodash escape, OWASP Encoder, he.js). &apos; (named) is only valid in HTML5/XHTML, making it a less portable choice for the general case.

No. Unlike a malformed URL Encoding sequence, an unknown or incomplete HTML entity simply stays as literal text — there's no such thing as an "invalid decode" in this tool.

Not on its own. It converts reserved characters for safe display as text inside the body of an HTML document — the same escaping frameworks like React already do automatically. It doesn't replace a real HTML sanitizer when the goal is inserting raw third-party markup, nor does it cover contexts with their own escaping rules (inside an attribute, a URL, a <script> block).

Yes. Decode uses a <textarea> element detached from the document — that element has a content model that never interprets its value as real elements, so no tag is executed or rendered; only character entities are decoded, and everything else stays as literal text in the output.