HTML Character Entities

HTML character entities are special codes used to display characters that either have a reserved meaning in HTML markup (like < and &) or that are hard to type directly on a keyboard (like © or €). Because the browser’s parser treats certain characters as the start of a tag or the start of an entity itself, you cannot simply type them into your page content — you have to “escape” them using an entity reference instead. Understanding entities is essential for writing valid HTML and for correctly displaying symbols, currency signs, accented letters, and mathematical notation.

Overview: How Character Entities Work

When the browser’s HTML parser reads your document, it scans character by character looking for markup delimiters. The character < (less-than) tells the parser “a tag is starting here,” and & (ampersand) tells the parser “an entity reference is starting here.” Because these characters are reserved for the parser’s own use, you cannot put a literal < or & into your visible text and expect it to display as-is — the parser will try to interpret it as markup, often producing broken or unexpected results.

Entities solve this by giving you an alternate, unambiguous way to represent these reserved characters (and thousands of other symbols) as plain text data instead of markup instructions. An entity reference is a short piece of text that the parser recognizes and replaces with a single character when it builds the DOM. Critically, this replacement happens during parsing — by the time the DOM tree exists, there is no entity left at all, only the resulting character as a text node. If you inspect the page in browser developer tools, you will see the actual rendered character (for example, an em dash or a copyright symbol), not the entity code you typed in the source.

There are three main forms of character references in HTML:

Named character references (named entities) — a mnemonic name wrapped between & and ;, such as © for © or & for the ampersand itself. These are easiest to read and remember.
Decimal numeric character references — &# followed by the character’s Unicode code point in base 10, then ;, such as © for ©.
Hexadecimal numeric character references — &#x followed by the code point in hexadecimal, then ;, such as © for the same © symbol.

Numeric references are extremely powerful because they can represent any Unicode character, including symbols that have no named entity at all (emoji, rare punctuation, characters from many world scripts). Named entities only exist for a defined set of common characters, but they are more readable to a human editing the source.

Syntax

&name;      (named character reference)
&#nnnn;    (decimal numeric character reference)
&#xhhhh;   (hexadecimal numeric character reference)

Part	Meaning
`&`	Marks the start of the character reference. Required.
`name`	A case-sensitive mnemonic, e.g. `lt`, `gt`, `amp`, `copy`, `nbsp`.
`#nnnn`	A decimal Unicode code point, e.g. `#169` for the copyright sign.
`#xhhhh`	A hexadecimal Unicode code point, e.g. `#xA9` for the same character.
`;`	Terminates the reference. Always include it — see Common Mistakes below.

Some of the most frequently used named entities:

Entity	Renders as	Meaning
`<`	<	Less-than sign
`>`	>	Greater-than sign
`&`	&	Ampersand
`"`	"	Double quotation mark
`'`	'	Apostrophe / single quote
` `	(a space that won’t break/wrap)	Non-breaking space
`©`	©	Copyright sign
`®`	®	Registered trademark sign
`™`	™	Trademark symbol
`—`	—	Em dash
`€`	€	Euro currency sign

Examples

Example 1: Escaping reserved characters so code displays as text

<p>To create a paragraph, use the &lt;p&gt; tag. Remember: 5 &lt; 10 &amp;&amp; 10 &gt; 5.</p>

Result: The browser displays the literal text: “To create a paragraph, use the <p> tag. Remember: 5 < 10 && 10 > 5.” None of the escaped symbols are interpreted as markup or as separate tags — they show up exactly as typed, as plain readable characters.

This is explained by the fact that each reserved character was replaced with its entity reference before being placed in the text. Because the parser never sees a literal < or & in the content, it never mistakes them for the start of a tag or another entity, so the text renders safely and predictably.

Example 2: Named entities for typographic and legal symbols

<footer>
  <p>&copy; 2026 BrightPath Studio &mdash; All rights reserved.</p>
  <p>WidgetPro&trade; is a trademark of BrightPath Studio&reg;.</p>
</footer>

Result: A footer section renders two lines of text: “© 2026 BrightPath Studio — All rights reserved.” and “WidgetPro™ is a trademark of BrightPath Studio®.” The copyright symbol, em dash, trademark symbol, and registered symbol all appear as proper typographic characters rather than as raw entity code.

This pattern is extremely common in real footers and legal text, where symbols like ©, ™, and ® are needed but are awkward or impossible to type directly from a standard keyboard.

Example 3: Numeric character references (decimal and hexadecimal)

<p>Decimal: &#169; &#8364; &#9829;</p>
<p>Hexadecimal: &#xA9; &#x20AC; &#x2665;</p>

Result: Both paragraphs render the same three symbols: the copyright sign (©), the euro sign (€), and a heart symbol (♥). The first paragraph uses decimal code points and the second uses hexadecimal code points for the identical characters, proving that decimal and hex references are just two notations for the same underlying Unicode values.

Numeric references are especially useful when there is no named entity available, such as for many emoji, arrows, or characters from scripts that don’t have a short mnemonic name defined in the HTML specification.

How It Works Step by Step

When the browser encounters an entity reference while tokenizing HTML text, it follows a consistent process:

The tokenizer is scanning character data (text inside an element, not inside a tag) and encounters an & character.
It looks ahead to see whether what follows forms a recognized named entity (matched against a fixed table defined by the HTML specification), a # followed by digits (decimal), or a #x/#X followed by hex digits.
If a valid reference is found (and properly terminated with a semicolon), the tokenizer resolves it to the corresponding Unicode code point and emits that single character as part of the text node.
If the & is not followed by anything that forms a recognized reference, most modern browsers fall back to treating it as a literal ampersand character rather than throwing an error — but this fallback behavior is not something you should rely on, since it can vary by context and is flagged as invalid by strict validators.
By the time the DOM tree is built, the entity no longer exists as a distinct concept — it is simply the resulting character, indistinguishable from a character typed directly (assuming your keyboard could type it).

Common Mistakes

Mistake 1: Using a raw, unescaped ampersand in text

<p>Terms & Conditions apply. Use & for "and".</p>

This is wrong because a bare & should always be escaped as & in HTML text. Even though many browsers will forgive an ampersand that isn’t followed by a valid entity name and just render it literally, this behavior is unreliable, fails strict validation, and can break unexpectedly if the following text happens to look like a real entity name (for example, Q&A is safe, but Terms & copyrights could be misread if &copy is later matched without you intending it).

Corrected version:

<p>Terms &amp; Conditions apply. Use &amp; for "and".</p>

Mistake 2: Forgetting the terminating semicolon

<p>Price: 10 &copy 2026</p>

Without the semicolon, some browsers may still recognize a small set of legacy entity names (like &copy without a semicolon, for historical compatibility), but many others will not, and the behavior is inconsistent across contexts such as inside attribute values. Always terminate every entity with a semicolon so the parser knows exactly where the reference ends.