HTML Entities Reference

HTML entities let you display reserved and special characters. This table covers the most common named entities with their decimal/hex numeric forms and descriptions.

How It Works

HTML entities encode characters that would break parsing or cannot be typed. Three must always be escaped: <, > and &, otherwise the browser treats them as tags or entity boundaries.

Entities come as named (&copy;, &nbsp;) or numeric (&#169;, &#x2022; hex). They both prevent XSS (turn a user's < into &lt;) and render symbols like copyright or arrows. But entities do not defeat whitespace collapsing — consecutive spaces are still merged by HTML.

When to Use This Table

This table is for writing special characters safely into HTML or recovering the original characters from HTML. It gives the named entity (&amp;), the decimal and hexadecimal numeric forms, and the purpose of each character. Generators, parsers, escaping and unescaping all depend on it.

When not to consult it: you are doing full HTML sanitisation or XSS defence. This table only explains what the characters are, not which ones to escape and when — that is a sanitiser library such as DOMPurify, and treating the entity table as a security checklist misses a great deal of attack surface.

Rule of thumb: judge by the role the character plays in the output position. In text nodes < > & " and need escaping; in attribute values it also depends on the quote style, since a single quote need not be escaped inside double quotes and vice versa; in URL parameters & and = are delimiters and must be encoded.

Mind the semicolon: HTML allows omitting the trailing semicolon (&amp parses as &), but inside a text node followed by a letter it becomes ambiguous (&ampx parses as &x). Always write the full semicolon for the best compatibility.

Boundaries and Common Pitfalls

  • Semicolons are optional and get silently reinterpreted when a letter follows

    HTML5 lets &amp without a semicolon parse as &. But if a letter or digit follows, the parser tries the longest match: in some parsers &ampx becomes &x (the x is absorbed into the entity name) rather than the literal &amp;x. That is silent content loss triggered only in specific contexts, which makes it extremely hard to debug. The rule is simple: always emit the full &amp;.

  • Entity encoding is not XSS defence — the browser decodes before parsing

    Writing < as &lt; only helps inside a text node. Put the same input into an attribute, a URL or a script context and the browser may decode entities at an earlier stage, defeating the protection: <img src=x onerror=alert(1)> placed in an unquoted attribute with angle brackets entity-encoded can still yield an executable event handler. The real fix is context-aware encoding (HTML text, attribute, JS string and URL each have their own rules) or DOMPurify for anything high risk.

  • Double encoding leaves an extra layer of literal text

    Encoding already-encoded text again turns &amp; into &amp;amp; and the page shows a literal &amp; instead of &. The usual trigger is double serialisation: the template engine auto-escapes and the code escapes again, or JSON embedded in HTML is passed through an encoding layer. Debug by inspecting the actual DOM text rather than the source, where multiple layers of &amp; are often normal.

How This Relates to Neighbours

To see what a character looks like and its code point, use the in-site ASCII and character-encoding pages; this one covers the HTML entity layer.

Percent-encoding in URLs (%20, %E4%B8%AD) belongs to the URL encoding page — it is a different mechanism from HTML entities.

To escape or unescape text in bulk, use the in-site HTML tools; this table is a semantic reference, not a processing pipeline.

If the goal is XSS defence, this table is not a sufficient basis — use a mature sanitiser together with CSP rather than hand-picking characters to escape.

Practical Snippet

Key points: (1) never omit the semicolon — when a letter follows, HTML5 longest-match absorbs it into the entity name and content is silently lost; (2) entity encoding only protects text nodes; attributes and script contexts need context-aware encoding or DOM-based construction, and anything high risk deserves DOMPurify plus CSP; (3) always quote attribute values, since an unquoted attribute breaks on the first space; (4) to unescape, use textarea or DOM parsing instead of hand-written regular expressions, which easily miss nested entities.

// ① 三个等价写法(分号都要写全)
const s = '&'      // &     字符
'&amp;'             // &amp;      命名实体
'&#38;'             // &#38;      十进制
'&#x26;'            // &#x26;     十六进制

// ② 用 DOM 构造而非字符串拼接(自动转义,最安全的默认做法)
const el = document.createElement('div')
el.textContent = '<script>alert(1)</script>'   // 纯文本,不解析为标签
el.innerHTML = '<script>alert(1)</script>'     // ⚠️ 会解析成真的 script
document.body.append(el)

// ③ 必须拼 HTML 时,转义「文本节点」的 5 个字符就够
const ESC = { '&’: ’&amp;’, ’<’: ’&lt;’, ’>’: ’&gt;’, ’"’: ’&quot;’, "’": ’&#39;' }
const esc = s => String(s).replace(/[&<>"']/g, c => ESC[c])

// ④ 属性值:按引号风格决定要不要转义单/双引号
const attrDouble = 'data-x="' + esc(userInput) + '"'   // 双引号包裹 ⇒ 单引号已转义
// ⚠️ 无引号属性最危险:空格即可逃逸,必须始终加引号
// <div class=USER>  ← USER 含空格就断了

// ⑤ 反转义:优先用 DOM,不自己写正则
const decode = html => {
  const d = document.createElement('textarea')
  d.innerHTML = html
  return d.value
}
console.log(decode('&lt;b&gt;'))    // <b>  (作为文本,不是标签)

// ⑥ 识别「实体没写分号」的隐患
const risky = '&ampx'                // 某些解析器解析为 &x,内容被吃掉
console.log(risky)                    // 始终写 '&amp;x' 才对

Practical Notes

  • Named entities end with a semicolon; omitting it makes the parser guessWhen the semicolon is missing the HTML parser falls back to the longest known entity: &amp still renders as &, but &notin becomes &not followed by "in". This is especially error-prone for & followed by letters inside attribute values, so always write the semicolon.
  • &nbsp; is a no-break space, not a regular spaceIts code point is U+00A0. Regexes that replace ordinary spaces (for example turning spaces into underscores) will silently skip it, while using it for layout prevents text from wrapping on narrow screens. Normalize U+00A0 to U+0020 during data cleanup.
  • Do not use entities inside <script> or preformatted blocks<script> is a raw-text element: its content is not entity-decoded, so writing &amp; lands literally in the JS string and can break syntax. In <pre>/<textarea> decoding does happen but rewrites the original input, so output already-escaped text instead.

Data Sources

  • WHATWG HTML Standard §13.5 (named character references)

Codes, names and definitions above come from public specifications; we claim no originality over the specification data itself. The arrangement, Chinese annotations and practical notes on this page are written by us.

NamedDecimalHexCharDescription
&amp;&#38;&#x26;&Ampersand; must be escaped in text/attributes
&lt;&#60;&#x3C;<Less-than; start of a tag, must be escaped
&gt;&#62;&#x3E;>Greater-than; end of a tag, must be escaped
&quot;&#34;&#x22;"Double quotation mark; escape in attribute values
&apos;&#39;&#x27;'Apostrophe; HTML5 ok, not in XML
&nbsp;&#160;&#xA0; Non-breaking space
&copy;&#169;&#xA9;©Copyright symbol
&reg;&#174;&#xAE;®Registered trademark
&trade;&#8482;&#x2122;™Trademark symbol
&hellip;&#8230;&#x2026;…Horizontal ellipsis
&mdash;&#8212;&#x2014;—Em dash
&ndash;&#8211;&#x2013;–En dash
&euro;&#8364;&#x20AC;€Euro sign
&pound;&#163;&#xA3;£Pound sign
&cent;&#162;&#xA2;¢Cent sign
&yen;&#165;&#xA5;¥Yen / Yuan sign
&times;&#215;&#xD7;×Multiplication sign
&divide;&#247;&#xF7;÷Division sign
&plusmn;&#177;&#xB1;±Plus-minus sign
&deg;&#176;&#xB0;°Degree sign
&sect;&#167;&#xA7;§Section sign
&bull;&#8226;&#x2022;•Bullet
&middot;&#183;&#xB7;·Middle dot
&laquo;&#171;&#xAB;«Left-pointing double angle
&raquo;&#187;&#xBB;»Right-pointing double angle
&sup2;&#178;&#xB2;²Superscript two
&sup3;&#179;&#xB3;³Superscript three
&frac12;&#189;&#xBD;½Vulgar fraction one half
&infin;&#8734;&#x221E;∞Infinity
&ne;&#8800;&#x2260;≠Not equal to
&le;&#8804;&#x2264;≤Less-than or equal to
&ge;&#8805;&#x2265;≥Greater-than or equal to

Frequently Asked Questions

Why use HTML entities?

In HTML, <, >, & and " are reserved characters that would be parsed as tags or entity syntax. Entities such as &lt; let you display the character itself safely.

Named or numeric entities — which is better?

Named entities (e.g. &copy;) are readable but depend on the spec name table. Numeric entities (&#169; / &#xA9;) reference Unicode code points directly, with broader compatibility and safer use in XML.

Do all characters need escaping?

No. Only the reserved characters (& < > " ') and quotes in attribute values need escaping; ordinary prose does not.

Does HTML5 support &apos;?

HTML5 supports &apos; (apostrophe), but XML/XHTML 1.0 does not; use the numeric entity &#39; for cross-document safety.