When you write <div> inside a web page, the browser does not render the angle brackets. It reads them as markup. To show a literal < on the page, you write < instead. That is an HTML entity: a text sequence that stands in for a character the HTML syntax would otherwise treat differently. This guide explains when entities are needed, the three ways to write them, and where the rules surprise people. The diagrams below run the real logic in your browser.

What an HTML entity is

An HTML entity is a placeholder in your source that the parser replaces with a single character. It lets you write characters that are either reserved by HTML syntax or simply awkward to type. Entities are not encryption, not compression, and not a different character set. They are a writing convention that resolves to ordinary Unicode characters when the page is parsed.

Entities only matter in HTML source. Once the browser has parsed the document, & is just the character & sitting in the text. If you inspect the rendered text with JavaScript, you will see the plain character, not the entity.

Why HTML needs entities

HTML uses a handful of characters for its own syntax. If those characters appear in your content, the parser cannot tell whether you meant markup or text.

• & introduces an entity, so a bare & can be misread as the start of one.
• < starts a tag, so a bare < can be misread as markup.
• > ends a tag, and matters most right after a <.
• " and ' delimit attribute values, so they must be escaped inside an attribute.

Leave these unescaped and the page can break or, worse, let user input inject its own tags. That injection path is the basis of cross-site scripting (XSS), so escaping content before it reaches the DOM is a security control, not just a formatting detail.

The three syntaxes

Every entity fits one of three forms:

• Named: a human-readable name, like &, ©, or  .
• Decimal numeric: a # followed by the character's Unicode code point, like ©.
• Hexadecimal numeric: a #x followed by the code point in hex, like ©.

Named entities are easier to read but only exist for a fixed list. Numeric references work for any character, which is why they are the safe fallback. Decimal and hex mean the same character; pick whichever you find clearer.

The characters you must encode

For everyday HTML, only a small set needs encoding in text content:

• & → &
• < → <
• > → >
• " → " (inside double-quoted attributes)
• ' → ' (inside single-quoted attributes)

Everything else, including accented letters and emoji, is fine as raw UTF-8 text in a modern document. You can encode any character numerically if you want, but you rarely need to. The diagram turns a string into entities one character at a time:

Three ways to write one character

The same character can be written three ways. Click through the grid to see the named form (when there is one), the decimal reference, and the hex reference for each:

The ampersand trap

The ampersand is the one character with a trap attached. An & only becomes an entity when it starts a valid entity name followed by a semicolon. Write AT&T and the browser leaves it alone, because &T is not a known entity. Write Tom & Jerry and it renders as Tom & Jerry. Write M&Ms and it stays M&Ms.

This matters because a missing semicolon or a near-miss name silently fails to decode. The box below uses the real browser parser, so what you type is exactly what a browser would show:

Non-breaking spaces and whitespace entities

Some entities are not about escaping syntax but about controlling layout. The most useful is  , a non-breaking space. It looks like a space but tells the browser not to start a new line there. That keeps short phrases like "New York City" or "100 km/h" from splitting across lines. Shrink the box below to see a normal space wrap while   holds the words together:

HTML entities versus URL encoding and Base64

Entities solve a different problem from the other two encodings you meet on the web:

• HTML entities target HTML markup. They keep <, &, and friends from being read as tags. They live in HTML source only.
• URL encoding targets URL syntax. It produces %XX so characters survive in a query string or path. Our URL encoding guide covers it.
• Base64 targets binary data. It turns bytes into text that is safe to embed anywhere. Our Base64 guide covers it.

A common slip is to use the wrong one: HTML-escaping a URL parameter leaves the & as &, which the server then reads literally, while URL-encoding the same value would have produced %26. Pick the encoding for the layer you are writing into.

Common mistakes

• Forgetting to escape &. Any & in text should be & unless it starts a real entity. A bare & is the most common source of rendering glitches.
• Double encoding. Escaping & again turns it into &, which renders as the literal text & instead of &.
• Using entities inside JavaScript strings. The HTML parser does not run inside a <script> block the same way, so & there stays as text, not a character. Escape for the JavaScript string, not for HTML.
• Trusting named entities everywhere. A name like © only decodes in HTML. In an attribute value, in CSS, or in JSON it means nothing. Use numeric references or the raw character when you are outside HTML text.
• Mixing layers. HTML-escaping a value that is about to be URL-encoded, or the reverse, produces output neither layer expects.

Recommended reading

Put it into practice with the HTML Entities tool, or escape strings for code with the String Escaper. For the surrounding concepts, read our web encoding guide, URL encoding guide, and Base64 guide.