HTML Entities Reference

An HTML entity is a way to write a character in HTML using a named or numeric reference instead of the literal character. The reference table above lists the common ones; this page explains the categories and when each is appropriate.

The structure

&        ← named entity
&        ← decimal numeric character reference
&       ← hex numeric character reference

All three decode to &. They start with &, end with ;, and have a name or #-prefixed number in between.

Which characters need escaping in this context?

For ordinary HTML text, escape & and < when inserting arbitrary text. Encoding > is allowed but is not normally required:

In quoted attributes, also escape the quote that delimits that value:

A double-quoted attribute can contain a literal apostrophe; a single-quoted one can contain a literal double quote. Prefer quoted attributes. These rules do not make an untrusted URL or JavaScript string safe: use the encoding and validation for the destination context.

Common useful named entities

Many of these aren’t strictly necessary in modern UTF-8 HTML — you can put © literally and it works. The named forms are conveniences for keyboards that can’t easily type the character.

Math and Greek

α α    β  β    γ  γ    δ  δ
π    π    σ σ    θ  θ    λ λ
∞ ∞    ≈ ≈    ≠     ≠    ≤     ≤    ≥ ≥
∑   ∑    ∏  ∏    ∫    ∫    ∂   ∂
∈  ∈    ∉ ∉    ∪    ∪    ∩    ∩

The full set covers most of basic math notation. For complex math typesetting, MathML or KaTeX/MathJax are better choices.

Arrows

← ←    → →    ↑ ↑    ↓ ↓
↔ ↔    ⇐ ⇐    ⇒ ⇒    ⇔ ⇔

Note the case difference: lowercase larr is single-stroke; uppercase lArr is double-stroke.

When to use entities vs literal characters

In a UTF-8 HTML document:

The historical reason for entities — handling characters that an ASCII source file couldn’t include — is mostly gone. Source files are UTF-8; characters can be literal.

Numeric vs named: when each is right

• Named is more readable in source. — is clearer to a human than —.
• Numeric represents many characters without named references; a literal UTF-8 character is another option. Invalid values such as zero or surrogate code points do not produce those characters: HTML parsing applies error-recovery rules.
• Hex numeric matches Unicode documentation conventions. 😀 corresponds to Unicode’s “U+1F600 grinning face.”
• Decimal numeric is equally valid; © and © both represent ©.

When in doubt: literal character if possible; named entity if encoding is needed and a name exists; hex numeric otherwise.

What about '?

' was not in HTML 4. It’s part of XHTML and HTML 5. Old HTML 4 parsers rejected it; everything modern accepts it.

If you’re hand-writing HTML for a 2026-era site, ' is fine. If you’re producing HTML for a system that has to be HTML-4-compatible (rare), use ' instead — the numeric form has always been valid.

Common pitfalls

• Forgetting the trailing ;. &amp (no semicolon) is sometimes accepted by lenient browsers but flagged by validators. Always include ;.
• Using   for layout. It’s a non-breaking space, not a hard space. Multiple   for indentation is the wrong tool — use CSS padding or margin.
• Confusing entity names with similar-looking ones. ' (apostrophe) vs ′ (prime mark) — different characters, different uses.
• Assuming entities work everywhere. HTML character-reference parsing applies to text and attribute-value contexts, not script/style source, JSON, or ordinary plain text. XML has its own entity rules; do not assume the full HTML named set is available.
• Confusing entities with HTML. Entities are character references, not markup. <b>hello</b> displays as the literal text <b>hello</b>, not as bold text.

For encoding/decoding directions, see HTML encode and HTML decode. For ASCII-specific lookups, ASCII table.

Sources and scope

Checked September 27, 2026: WHATWG HTML syntax and OWASP output-encoding contexts. The table is a character lookup, not an HTML sanitizer.