Named vs Hex vs Decimal HTML Entities: What Actually Differs

Three ways to write the same character

HTML gives you three notations for any character you cannot or do not want to type literally. Take the copyright sign, U+00A9:

• Named: © — a mnemonic defined in the HTML specification.
• Decimal: © — the code point expressed in base ten.
• Hexadecimal: © — the same code point expressed in base sixteen, prefixed with x.

All three resolve to the same character before any script runs. The differences that matter are coverage, length, and where the document is going to be parsed — not the numeral system.

The number in brackets is the character count of the reference itself. It is not trivia: on a page with thousands of encoded characters, the notation you choose is a real difference in bytes shipped.

Coverage is the only decisive difference

The named table is finite and closed. HTML5 defines 2,231 named character references, and that list does not grow with Unicode — the code points assigned since the last revision have no names at all. Anything outside the table has to be written numerically.

That is the whole argument for numeric references, and it is a coverage argument rather than a strength argument. A numeric reference can address any code point up to U+10FFFF, which means a single implementation handles Latin accents, Cyrillic, Chinese, mathematical alphanumerics and emoji without a lookup table. An encoder built on names needs a fallback for everything it has not got a name for, and a fallback that is missing is how an unencoded character ends up in the output.

There are two related subtleties in the named table itself. First, some names expand to more than one code point: there are entries that map to a base letter followed by a combining mark, so a name is not always a synonym for one character. Second, several names are visually identical to each other and differ only in normalization form, which means two strings that look the same on screen can compare unequal. Numeric references avoid both problems because the mapping is one number to one code point.

Where hex has a genuine edge

Hexadecimal notation wins on lookup, not on safety. Unicode documentation, character maps and font tools all quote code points in hexadecimal, so ’ can be verified by reading the same source that told you the character is U+2019. Going from U+2019 to ’ requires a base conversion in your head.

Hex is also shorter for anything above U+FFFF. An emoji at U+1F600 is eight characters as 😀 and nine as 😀. Below that the positions reverse: a three-digit decimal code point such as U+00E9 is six characters as é and six as é, and a four-digit one such as U+2019 is seven as decimal against eight as hex. Neither notation is uniformly more compact.

Two mechanical details are worth knowing. Hex digits are case-insensitive in HTML, so © and © are the same reference, though upper case matches how code points are conventionally written. Leading zeros are optional, so © and © are also identical. The terminating semicolon, by contrast, should always be written: HTML has legacy error-recovery rules that allow it to be dropped in some contexts, and relying on them produces references that break depending on the character that follows.

Where entities do not work at all

HTML entities are an HTML feature, and they are inert everywhere else. That trips people up in three places:

• JavaScript strings. \u00A9 and \u{1F600} are the escape forms. An HTML entity inside a string literal is just those characters, and if that string is later written into the DOM with textContent it will display literally.
• CSS. The form is a backslash and the hex code point, as in content: "\00A9". A trailing space terminates the escape when the next character would otherwise be read as a hex digit.
• XML and SVG. XML predefines exactly five entities — ampersand, less-than, greater-than, quote and apostrophe. Any other named entity requires a document type definition that declares it, so a named reference copied from an HTML page into an SVG file can fail to resolve. Numeric references work in XML without any declaration, which is one more argument for the numeric forms in mixed documents.

Choosing between them

• Use named entities for the handful of characters that carry meaning and appear constantly: ampersand, angle brackets and quotes. Their readability is worth more than the few bytes.
• Use numeric references for everything else, because coverage is guaranteed and no fallback is needed.
• Choose hexadecimal when you are transcribing code points from Unicode documentation, and decimal when you are working in an environment whose tooling emits decimal.
• Never mix notations for the same character within one codebase. The browser does not care, but the next person comparing two files for a diff does.

Whichever you pick, the practical rule is the same one that applies to all escaping: encode the complete dangerous set, encode it once, and be sure the character you are encoding is genuinely in the set. The notation is a style decision. The completeness of the set is the correctness decision, and it is the one that shows up as a broken page rather than as an untidy diff.