HTML entity inspector — named / decimal / hex / Unicode name side by side

The text you inspect for entities often contains operational content

The need to inspect HTML entities arises when working with template output, CMS bodies, mail HTML, or logs that have escaped text. Those sources can contain user-submitted content, API response fragments with personal data, or excerpts from internal documents. Pasting that text into an online entity inspector sends the content alongside the question about the entity — the two are inseparable once the paste happens.

The “paste an already-escaped log” workflow is particularly risky: the surrounding text frequently still contains sensitive values that were meant to be sanitised — email addresses, token fragments, internal URLs — and those values travel along with the entity you actually wanted to look up.

Reference-style tools that quietly round-trip through a server

Dictionaries, references, and cheatsheet-style tools project a sense of “I’m not really sending data”, but many implementations POST the input string to a backend to produce the result. The UI rarely lets you distinguish a fully client-side lookup from one that round-trips through a server with logging — both look like a search box returning matches.

Terms of service often include clauses authorising the retention of inputs for “aggregate statistics” or “anonymised improvement logs”, and the user side rarely re-reads them per session. Because the perceived task (“just looking something up”) is so lightweight, the structural decision to ship content outside your environment slips past attention more easily than with explicitly transactional tools.

The full WHATWG HTML5 entity list bundled for offline lookup

This tool bundles all 2125 named entities from the WHATWG HTML5 specification at build time. Entity detection, named-form lookup, and numeric-reference generation all happen in browser memory — no external API query. Named-entity presence checks are O(1) hash-map lookups against the bundled dictionary.

Decimal and hex numeric references are decoded with parseInt() and String.fromCodePoint(), which need no dictionary. Open DevTools Network and type an entity: no request fires.

Choosing the right entity notation for your context

Whether to use named, decimal, or hexadecimal numeric notation when writing HTML depends on the audience and the output target. This tool lets you see all three forms for any character in one row, so the decision is immediate: ™ exists and is human-readable; ™ is more portable; ™ aligns directly with the Unicode code point. For machine-generated HTML and production code, hex numeric references cover every Unicode code point unambiguously. For human-authored source, named entities are easier to read and edit.

Semicolon-optional entities in the WHATWG parser

The HTML5 spec defines a quirky legacy clause that allows certain named entities to be parsed without a trailing semicolon. &amp (no semicolon) decodes to & just like & does, preserved as a backwards-compatibility measure for older documents. Roughly one hundred historically common names (&amp, &lt, &gt, &quot, &copy, &reg, …) participate; newer entities like &CounterClockwiseContourIntegral require the semicolon.

This semicolon-optional behaviour is also a trap that can mangle URLs in HTML attributes. Writing ?param=foo&copy=bar inside an attribute makes the browser decode &copy as © and expand it to ?param=foo©=bar. The remedy is to always escape & as & inside attribute values. Cross-checking against the “decodes without semicolon” list in this tool helps spot which names will trigger this in raw URLs.

Different treatment in XML, SVG, and MathML

Of the 2125 named entities HTML supports, XML recognises only five by default: &, <, >, ", '. SVG and XHTML processed as XML throw “undefined entity” errors on © or ™. The fixes are (a) declare the needed entities in a DTD, or (b) rewrite as numeric references.

For documents that need XML compatibility — SVG files, Atom feeds, XHTML-served pages, EPUB internal XML — using numeric references like © from the outset is the safer baseline. MathML adds yet another entity set (e.g. ⁢); HTML parsers recognise these because the WHATWG spec gives MathML and SVG contexts special handling. When scripting XML subtrees, looking up the hexadecimal numeric form (&#xXXXX;) of each character here keeps the output portable across XML and HTML consumers. For batch encode / decode of whole bodies, html-encode handles the bidirectional pass, and unicode-normalize is the right companion when entity name lookup keeps missing matches because the source is in NFD where the dictionary expects NFC.