HTML Entities: A Quick Reference and How They Work

An HTML entity is a short text code, beginning with an ampersand and ending with a semicolon, that a browser replaces with a specific character when it renders the page. Entities exist to solve two problems: some characters are reserved because they are part of HTML syntax, and some characters are hard to type or easy to get wrong. Rather than embedding the raw character, you write a stable code such as < or © and let the parser produce the real glyph. Understanding when an entity is required, when it is merely convenient, and when it is unnecessary is the difference between markup that renders cleanly and markup that leaks stray symbols or breaks outright.

What exactly is an HTML entity?

An HTML entity is a named or numeric reference to a single character. It has a fixed shape: an ampersand, a body, and a terminating semicolon. The body is either a name from a published list or a numeric code point. When the parser encounters the sequence, it does not treat the individual letters as literal text; it looks up the reference and substitutes the character it stands for.

There are two flavours. A named entity uses a readable label, such as © for the copyright sign or   for a non-breaking space. A numeric entity uses the Unicode code point of the character, either in decimal as © or in hexadecimal as ©. Named entities are limited to the characters HTML has defined names for, while numeric entities can express any character at all, which makes them the fallback when no name exists.

The semicolon is not decorative. Leaving it off produces unreliable behaviour, because the parser has to guess where the reference ends. Always terminate an entity with its semicolon.

Which characters must you escape, and why?

You must escape the characters that the HTML parser would otherwise interpret as markup. The rest are optional. There are only a handful that are genuinely mandatory, and the reason each is reserved comes straight from how the parser reads a document.

In ordinary body text, only the less-than sign and the ampersand are strictly required. The less-than sign is dangerous because 3 < 5 written literally makes the parser try to open a tag called 5. The ampersand is dangerous because Tom & Jerry written literally invites the parser to read an entity that was never intended, and depending on what follows it may consume characters or render incorrectly. Inside an attribute value, you additionally escape whichever quote character delimits the value, because an unescaped matching quote ends the value in the wrong place.

Named versus numeric: which should you use?

Prefer named entities when a name exists and it makes the markup clearer, and fall back to numeric entities for everything else. Named entities like ©, —, and … are self-documenting: a person reading the source can see what was intended. Numeric entities are universal but opaque, since — tells you nothing until you look it up.

A few widely used named entities are worth memorising:

•   — non-breaking space, which prevents a line break between two words
• © and ® — copyright and registered-trademark signs
• — and – — the em dash and en dash
• … — a horizontal ellipsis as a single character
• × and ÷ — multiplication and division signs

Numeric references shine for characters with no name or for programmatic escaping, where a routine simply converts any risky character to its code point without consulting a name table. Both forms produce identical output; the choice is about readability and tooling, not correctness.

Do you still need entities on a UTF-8 page?

For most characters, no. If your document declares UTF-8 encoding and your editor saves in UTF-8, you can type an em dash, an accented letter, a currency symbol, or an emoji directly into the source, and it will render correctly. Encoding solves the typing-and-display problem for you, so entities are not needed just to show an unusual glyph.

What encoding does not change is the structural role of certain characters. The less-than sign, the ampersand, and the delimiting quote inside an attribute still have syntactic meaning to the parser no matter what encoding the file uses. So even on a fully UTF-8 page you must escape those. A good working rule: use direct characters for anything that is purely content, and reserve entities for the characters that are part of HTML’s own grammar.

What goes wrong, and how do you debug it?

The two classic failures are under-escaping and double-escaping, and they look opposite on the page. Under-escaping means a raw < or & reached the browser and was misread, so part of your text vanished into a phantom tag or a malformed entity. Double-escaping means text was escaped twice, so a visitor sees the literal & or < on the page instead of the character.

Intended text:  Rock & Roll <3
Under-escaped:  Rock & Roll <3        <- browser may drop "3"
Correct once:   Rock &amp; Roll &lt;3
Double-escaped: Rock &amp;amp; Roll  <- literal &amp; shows up

The cure for both is the same principle: escape exactly once, at the single boundary where untrusted or raw text is turned into HTML. If your templating layer already escapes output, do not escape again by hand, and if you escape by hand, make sure the template is not also doing it. This same discipline is what keeps user-supplied text from being interpreted as markup, which is the foundation of preventing injection: treat data as data, and let one clearly defined step convert it to safe HTML.

When you need to see what a string looks like once encoded, or to decode an entity-laden blob back to plain text, our HTML entities encoder and decoder does the conversion in the browser so you can inspect both directions quickly. Because it runs client-side, whatever you paste stays on your machine, which is the right default when the text might contain anything sensitive. For the wider picture of escaping across contexts, the companion article on escaping strings in JSON, HTML, and URLs explains why each context needs its own rules.

What is a practical reference to keep handy?

The short list below covers the vast majority of real-world needs. For structural characters, escaping is about correctness; for the rest, it is about convenience when you cannot easily type the glyph.

Keep the mental model simple. Entities are the parser's way of letting you write characters that would otherwise confuse it or that you cannot easily type. Escape the three or four structural characters always, type everything else directly on a UTF-8 page, reach for a named entity when one exists and a numeric one when it does not, and encode precisely once. Follow that and stray symbols, disappearing text, and doubled ampersands stop appearing in your pages.