Skip to content
Everyday Utilities Free · No signup · Private · Instant results

HTML Entity Encode/Decode

Encode special characters to HTML entities or decode them back, per WHATWG HTML spec.

About the HTML Entity Encode/Decode

The HTML Entity Encoder & Decoder on HT99 Tools converts between literal characters and HTML entity references. The five characters that have syntactic meaning in HTML — &, <, >, ", ' — must be encoded as entities whenever they appear as text content or attribute values, otherwise the browser may interpret them as markup.

Encoding is the first line of defence against cross-site scripting (XSS). If you render user-supplied input into a page and forget to escape <script>, the browser will execute that script. The OWASP Encoder Project and the WHATWG HTML Living Standard §13.5 both list exactly these five characters as the minimum set that must be escaped in text content.

This tool offers both named entities (&amp;, &lt;, &gt;, &quot;) and numeric character references (&#38;, &#60;, &#62;, &#34;). Numeric references are preferred when maximum compatibility is required, because named entities are not understood by every XML parser.

Context matters: text content needs only &, <, and > escaped. A double-quoted attribute value also needs " escaped; a single-quoted value also needs '. The tool offers the single-quote escape as an option because most modern templates use double-quoted attributes and can skip it — but enabling it costs nothing and protects against the case where a developer switches quote style later.

How It Works

The WHATWG HTML Living Standard §13.5 (the Named Character References table) defines over 2,000 named entities, but only five are needed for safe escaping: &&amp;, <&lt;, >&gt;, "&quot;, '&#39;. The order matters: & must be replaced first, or the other replacements would themselves be re-encoded.

The single-quote entity uses the numeric form &#39; because &apos; is defined in XML but is not in the HTML 4 specification and was only added to HTML5 — some legacy parsers (notably Internet Explorer) do not understand &apos;. Numeric references work everywhere.

Decoding uses the browser's own parser: a <textarea> element is created, its innerHTML is set to the encoded string (which the browser parses, resolving every entity), and the value property is read back. This approach handles every named entity, every numeric reference (decimal and hex), and is identical to what the browser does when it renders your page.

Worked Examples

Encoding the default input Render this literally: <script>alert("XSS")</script> & <b>bold</b> tags. with named entities produces Render this literally: &lt;script&gt;alert(&quot;XSS&quot;)&lt;/script&gt; &amp; &lt;b&gt;bold&lt;/b&gt; tags.. Paste that into an HTML file and the browser will display the original text verbatim, without executing the script.

Switch to numeric mode and the same input becomes Render this literally: <script>alert("XSS")</script> & <b>bold</b> tags. — identical behaviour, but each entity works even in XML parsers that do not know the HTML named entities.

Decoding reverses either form. Pasting caf&eacute; &amp; cr&#232;me yields café & crème, correctly resolving both the named &eacute; and the numeric &#232; to the same character.

When to Use This Tool

  • Escaping user input before rendering it as text content (the single most common XSS defence).
  • Encoding text for inclusion in an HTML attribute value (where both quotes may appear).
  • Displaying code snippets in a blog post so that <div> renders as text, not as a div.
  • Decoding entity-encoded strings received from RSS feeds or XML APIs.
  • Producing numeric-only entities for output that must be valid in both HTML and XML.
  • Inspecting emails encoded with &quot; and &amp; to read the literal subject lines.
  • Sanitising CMS content before it is fed into a search indexer.

Limitations & Disclaimer

The tool escapes the five HTML-significant characters only. It does not escape Unicode control characters, null bytes, or surrogate-pair characters. It is not a full HTML sanitiser: it will not strip <script> tags — it will escape them so the browser renders them as text, which is the correct behaviour for displaying code but is not a substitute for a sanitiser like DOMPurify when the input is meant to be rendered as live HTML. The decoder resolves every named entity the browser supports, which is over 2,000 — but not every entity is round-trip-stable across browsers. See our disclaimer for full terms.

Frequently Asked Questions

Which characters absolutely must be escaped in HTML?

The five characters <code>&amp;</code>, <code>&lt;</code>, <code>&gt;</code>, <code>"</code>, <code>'</code>. <code>&amp;</code> must be escaped first (otherwise the other escapes are re-encoded). <code>&lt;</code> and <code>&gt;</code> are needed for text content; <code>"</code> and <code>'</code> are needed when the text appears inside a double- or single-quoted attribute value. Everything else is optional.

Named entities vs numeric references &mdash; which is better?

Numeric references (<code>&amp;#60;</code>) work in every HTML and XML parser; named entities (<code>&amp;lt;</code>) work in HTML5 and XML 1.0+ parsers but not always in legacy XML tools. For maximum compatibility (e.g. RSS feeds, Atom feeds, embedded SVG), prefer numeric. For human-readable HTML, named entities are clearer.

Why does the tool use &#39; instead of &apos; for single quotes?

Because <code>&amp;apos;</code> was not part of HTML 4 and was added only in HTML5. Internet Explorer (and a handful of XML parsers) does not understand <code>&amp;apos;</code> and will render it literally. <code>&amp;#39;</code> is the numeric reference for U+0027 and works everywhere &mdash; the WHATWG HTML spec itself recommends it for that reason.

How does the decoder work?

The tool creates an in-memory <code>&lt;textarea&gt;</code> element, sets its <code>innerHTML</code> to the encoded string (which the browser's HTML parser resolves, expanding every entity), and reads back the <code>value</code> property. This is exactly what the browser does when it renders your page &mdash; so the output is guaranteed to match real-world rendering.

Does escaping protect me from every XSS attack?

No &mdash; only from XSS that injects markup through text content or attribute values. Escaping does not protect against DOM-based XSS (where JavaScript reads <code>location.hash</code> and writes it to <code>innerHTML</code>), script injection through <code>javascript:</code> URLs, or unescaped output inside <code>&lt;script&gt;</code> blocks (which has its own escaping rules). Use a defence-in-depth strategy &mdash; CSP, sanitisation, and contextual encoding.

Is my text uploaded anywhere?

No. Encoding and decoding run entirely in your browser. Code samples, HTML snippets, and PII never leave the device.

Last updated: September 9, 2026  ·  Author: HT99 Tools Editorial Team