How HTML Entities Work

HTML has a handful of characters with special jobs: < opens a tag, > closes one, & starts an escape, and quotes wrap attribute values. To display any of them as ordinary text — or to ship a character your keyboard does not have — HTML leans on entities: short escape sequences that stand in for literal characters.

Three ways to write one character

An entity starts with & and ends with ;, and comes in three forms:

<      named     (a mnemonic name)
&#60;     decimal   (Unicode code point 60 = <)
&#x3C;    hex       (the same code point in hexadecimal)

All three render as <. Named entities cover the common cases — HTML5 defines around two thousand of them — but any character can be written numerically: the euro sign is €, a non-breaking space is   (the famous  ), and the copyright sign is © or ©. Numeric references always work; names are a convenience layered on top.

The five characters you must encode

Five characters may appear in raw text only as escapes: < and > for the angle brackets, & for the ampersand itself, and " and ' for the two quote characters. The apostrophe is usually written as the numeric ' because it works everywhere; the named form ' is valid HTML5 but was not part of HTML 4. An encoder tool produces these five and decodes the standard ones back — which sounds trivial until you meet the ordering rule:

encoding: escape &amp; FIRST  → "<" becomes &lt;, not &amp;lt;
decoding: unescape &amp; LAST  → "&amp;lt;" becomes "&lt;", not "<"

If < is escaped before &, the newly created & sequences get escaped again and every < is double-escaped. Decoding has the mirror-image trap: unescape & first and < collapses to < — text that was safely escaped once becomes live markup. Handling each direction in the right order is the entire correctness test for an entity encoder.

Escaping as a safety tool

The mechanism that displays < as text also defangs untrusted content. If a comment, search query, or form field is escaped before it is placed in a page, whatever tags it contains render as harmless text instead of live markup — the browser sees the entities and prints <script> rather than executing it. That is why everything that renders user-supplied text escapes it first. The same discipline protects converters: the Markdown-to-HTML pipeline described in Markdown Explained escapes <, >, and & before applying any Markdown rules, so pasted content can never smuggle raw HTML into the output. Code samples need it too: wrap them in <pre><code> and escape the brackets, or the browser will try to interpret the markup you meant to display.

Details worth knowing

Entity names are case-sensitive: < is defined, < is not — a few names like & have uppercase twins, but you cannot rely on it. Attribute values need the same escaping as element text, plus the quote character that delimits the attribute itself: inside title="..." a literal double quote would end the attribute early, which is the everyday job of ". In plain element text, quotes are legal unescaped — encoding them anyway is harmless and keeps the habit uniform. Even spacing has an entity:   is a space the renderer refuses to break a line at, which is why glued-together measurements like 10 km never split across lines. Finally, note that modern pages are UTF-8, so most characters can be pasted directly into the source; entities remain essential for the five specials, for safety escaping, and for characters that are hard to type or hard to tell apart.

Try it yourself

Convert text to entities and back with the HTML Entity Encoder — try <b>, confirm you get <b>, then decode it again and watch the ordering rule hold. See what unescaped markup costs with the HTML to Text Converter, which strips tags and hands back clean plain text with line breaks preserved. And to audit a document's structure before or after conversion, the HTML Tag Extractor counts every tag and lists all attributes, classes, ids, and href/src values in the snippet.