An HTML entity is the markup-safe spelling of a character: an ampersand, a name or number, a semicolon. & renders as &, < as <, © as ©, and the numeric © or © reaches the same copyright sign through its Unicode code point. That's the whole mechanic. What trips people up is the surrounding rules: which characters actually need escaping, why there are three syntaxes, and the traps (nbsp, case sensitivity, double decoding). This guide covers all of it, with a table you can paste from.
Every entity names a Unicode code point, and every Unicode character can be written three ways in HTML:
| Form | Syntax | Example | Renders |
|---|---|---|---|
| Named | &name; | é | é (code point 233) |
| Decimal | &#NNN; | é | é |
| Hex | &#xHH; (x or X) | é | é |
The three are interchangeable in output but not in tooling. Named entities are the readable choice for hand-written HTML. Decimal and hex work everywhere, including environments that only understand a few names — XML, for instance, defines exactly five named entities (& < > " ') and requires numeric references for everything else.
Less than most escaped documents contain. The rules for text content:
& — escape it when the following text could look like an entity. In practice, escape it always; a bare & followed by amp; renders as a literal & in HTML5's forgiving parsing but breaks XML entirely.< — escape always in text. <script> in your text becomes a real script tag otherwise.> — technically forgivable in text (a stray > renders as itself), but escape it anyway; it costs two characters and removes a class of template bugs.title="He said "hi"" works; title='He said "hi"' also works.Everything else — accented letters, currency symbols, emoji — needs no entity at all in a UTF-8 document. Entities for those exist for three honest reasons: keyboards that can't type them, systems that mangle encodings, and source code where the raw character would be invisible or confusable (two of them, and soft hyphen, are genuinely invisible).
is U+00A0, a non-breaking space. Two things make it special: browsers won't collapse runs of it (normal spaces collapse to one) and won't break lines at it. Paste one from a rendered web page into a code editor or terminal and you get a "space" that breaks parsing, diffing, and column alignment, because it isn't a space. The same goes for ­ (soft hyphen, U+00AD) and ‌/‍. When a string with "invisible" bugs shows up, decoding entities and grepping for U+00A0 is the standard first move — the HTML entity converter makes that a two-click job.
Names are case-sensitive, and the case usually carries meaning. π is lowercase π (945) while Π is uppercase Π (928). © and © both map to the copyright sign in HTML5's table, but &Copy; is nothing. Since the safe mental model is "names are case-sensitive, full stop," generators avoid the whole question by emitting numeric forms.
Text in, entities out — named, decimal, or hex — and entities back to characters, all in your browser.
Open the HTML Entity Converter →The string &lt; is what you get when someone escapes the literal text <. Decoding it once yields < — correct. A decoder that loops until nothing changes would yield <, silently corrupting double-escaped content, which is exactly how stored-XSS bugs sneak through naive template systems. The HTML5 spec's own parsing decodes entities in one pass per text node. Any tool you use should do the same, and should leave unknown names (&fakeentity;) untouched rather than guessing.
HTML5 defines 2,231 named character references — 2,125 with semicolons, plus legacy semicolon-less forms like © that survive from HTML 3.2 for browser-compatibility reasons nobody should rely on today. About 121 names cover daily writing: the markup specials, currency, typographic punctuation, math symbols, Greek letters, and the accented Latin-1 set. That's the working set in our converter's map; anything outside it falls back to numeric automatically.
For anything serious — parsing untrusted HTML, handling XML, mapping all 2,231 names — the JavaScript ecosystem standardizes on fb55/entities, a BSD-2-Clause licensed package that underlies the htmlparser2 family and ships encode/decode maps for both HTML and XML modes. It's the right dependency when a regex stops being enough; the license is permissive enough for commercial embedding with attribution preserved.
Three escaping systems that show up in the same bug reports but solve different problems:
%20, %C3%A9) protects characters from URI syntax — spaces, ampersands in query strings, non-ASCII in URLs. The URL parser shows both sides of it.Picking the wrong layer is a classic integration bug: percent-encoding HTML doesn't stop it from being parsed as markup, and entity-encoding a URL breaks the URL. Match the escape to the parser that will read the string.
In text content: &, <, and (practically) >. The ampersand only strictly needs escaping when what follows could parse as an entity, and < only when followed by a letter, /, ! or ?, but escaping all three unconditionally is the safe habit. In attribute values, also escape the quote character delimiting the attribute. Everything else is optional; entities for accented letters and symbols are a compatibility convenience, not a requirement in UTF-8 documents.
Named for the specials (& < >) because they read clearly in source. Numeric for everything else if the output feeds a system that only understands a subset of names — email clients, older CMS templating, some XML processors. XML defines exactly five named entities, so numeric is the only portable choice there. If your document is UTF-8 and stays UTF-8, raw characters are usually fine and smaller.
Encoding mismatch. The document claims one character encoding (say ISO-8859-1) while the bytes are in another (UTF-8), or vice versa, so U+00A0 or the entity's target renders through the wrong table. Declare <meta charset="UTF-8"> as the first thing in head, send the matching Content-Type header, and the problem disappears.
Only for markup-significant characters. Modern HTML is UTF-8 by default, so é, ©, and even emoji can be written as raw characters. Entities remain mandatory for & < > in text, useful in generated HTML where you can't be sure of the encoding, and handy in email HTML where client support is years behind browsers.
The de facto standard is fb55/entities (BSD-2-Clause licensed), which powers the htmlparser2 ecosystem and supplies decode/encode maps for HTML and XML. For a handful of characters, a regex over named and numeric patterns is fine — this site's converter does exactly that in about 40 lines — but for untrusted input a maintained library handles the 2,231 HTML5 names, entity edge cases, and XML's stricter rules for you.