HTML Entities Encoder / Decoder

HTML reserves a handful of characters for markup — < starts a tag, > ends one, & starts an entity reference, and quotes delimit attributes. When you need those characters to appear as literal text rather than syntax, you write them as entity references: a name or number preceded by & and followed by ;. &lt; displays as <, &gt; as >, &amp; as &, and &quot; as ".

The mechanism exists because of HTML's character-data rules: a parser scanning text encounters < and assumes a tag follows, so there is no way to express a literal < without some escape hatch. Entities are that hatch — a well-defined sequence that any HTML parser must interpret as the character itself, never as markup.

Named entities are the memorable ones — &amp; &lt; &gt; &quot; &apos; &nbsp; &copy; &mdash; — and there are over 2,000 of them covering most of Unicode. Numeric character references name characters by code point instead: &#38; is decimal (38 = &), &#x26; is hexadecimal (0x26 = 38). Both forms render identically; the choice is about readability and coverage.

Numeric references are the fallback for anything without a common name — there's no named entity for an obscure CJK character or a rare symbol, but every Unicode code point has a number. They're also the right tool for characters that would be unsafe or ambiguous if typed literally: a literal & in text that isn't part of an entity is technically invalid HTML, while &#38; always works.

In element content, only three characters strictly require escaping: < (which starts a tag), & (which starts an entity), and > (which is safe in practice but escaped for symmetry and because ]]> in a script block terminates a CDATA section). In attribute values, the quote character matching the attribute's delimiter — " in double-quoted attributes, ' in single-quoted ones — must also be escaped, or the attribute value terminates early.

Beyond the required minimum, escaping non-ASCII characters is optional in any document served as UTF-8 — the browser already knows the encoding — but it becomes necessary when the output encoding is unknown or legacy (Latin-1, say) and the character falls outside it. That's why many tools escape all non-ASCII by default: it's safe in every context at the cost of longer, less readable source.

Cross-site scripting (XSS) is injection: user input containing <script> or onerror= attributes gets interpreted as markup when your page renders it. Encoding on output — converting < to &lt; and so on — neutralizes those characters so they display as text instead of executing as code. The key insight is that encoding is context-dependent: the same string needs different treatment in HTML body, an attribute, a URL, a JavaScript block or CSS.

The most common XSS bug is encoding in the wrong context or at the wrong layer. HTML-escaping a string that's then dropped into a JavaScript string literal doesn't stop injection — the JS parser has its own escaping rules — and encoding twice (&amp;amp;) shows the user the literal text "&amp;" instead of "&". Every modern framework handles per-context escaping by default; the attacks that slip through usually involve hand-built HTML in templates that bypass the framework's escaping.

"Encoding" and "escaping" are often used interchangeably, but the distinction matters in one specific scenario: encoding converts characters to entity references for HTML; escaping can mean several things — URL percent-encoding for query strings, backslash-escaping for string literals, or HTML entity encoding. Mixing them up produces bugs: URL-encoding an HTML attribute value corrupts it with % sequences, and HTML-encoding a URL puts &amp; into your href where an & was meant literally.

The double-encoding trap is the classic mistake: text that's already &amp; gets encoded again to &amp;amp;, which renders as the literal "&amp;" on the page — visible garbage to the user. It happens when a value passes through two layers of encoding: a database layer that escapes and a template layer that escapes again. The fix is to encode exactly once, as late as possible — at the point of output — and store values in their plain, unencoded form everywhere upstream.