What HTML Entities Are and Why They Exist
HTML entities are text sequences that represent characters which either have special meaning in HTML syntax or are difficult to type on a standard keyboard. The concept dates to the earliest days of SGML, the markup language that HTML descended from, when documents were routinely transmitted over systems that could only handle 7-bit ASCII. Entities provided a way to represent characters outside that range using only safe ASCII characters.
An HTML entity takes one of two forms. Named entities use a human-readable name wrapped in an ampersand and semicolon: & produces an ampersand, © produces the copyright symbol ©, — produces an em dash —. Numeric character references use either decimal (© for ©) or hexadecimal (© for the same character) code points from the Unicode standard. Named entities are defined by the HTML specification and vary between HTML versions — HTML5 defines a comprehensive list of over 2,000 named entities, while HTML 4.01 defined far fewer. Numeric references always work because they map directly to Unicode, which is version-independent.
The browser's HTML parser converts every entity back to its character before rendering. From the DOM's perspective, &lt; and the raw less-than character < are identical once the parser has processed the document. The distinction matters only in the raw source text that the parser is reading — which is precisely where it matters for security and correctness.
The Five Characters You Must Always Escape
The HTML specification identifies a small set of characters that have structural meaning in the HTML syntax. Placing them literally in text content or attribute values causes the parser to misread the document structure, producing broken rendering or security vulnerabilities. These five must always be escaped when appearing as content rather than markup.
The ampersand (&) opens every entity reference. A literal ampersand in text — common in company names, URLs, and mathematical expressions — must be written &amp; to prevent the parser from treating the following text as an entity. The less-than sign (<) opens every HTML tag. A literal < in inline code, mathematical inequalities, or template expressions must be &lt; to prevent the parser from treating what follows as a new tag. The greater-than sign (>) closes tags; while modern parsers tolerate literal > in text content in many positions, the spec requires it to be escaped as &gt; in attribute values and recommends escaping it everywhere for correctness. The double quote (") must be escaped inside double-quoted attribute values: <a title="Smith &quot;Ace&quot; Jones">. The single quote (&apos;) must be escaped inside single-quoted attribute values, though &apos; is an HTML5 addition not present in HTML 4 — &#39; is the universal safe form.
Every other character can safely appear as raw UTF-8 in a UTF-8 encoded document. The © symbol, em dash, non-breaking space, and even emoji are all legal in body text without escaping. The decision to use entities for them is a style preference, not a technical requirement.
The 50 Most Common HTML Entities Reference
The following table covers the entities that appear most frequently in real-world HTML documents, grouped by purpose.
Typography and punctuation: &mdash; (—, em dash), &ndash; (–, en dash), &hellip; (…, ellipsis), &laquo; («, left double angle quote), &raquo; (», right double angle quote), &ldquo; (“, left double quote), &rdquo; (”, right double quote), &lsquo; (‘, left single quote), &rsquo; (’, right single quote / apostrophe), &middot; (·, middle dot), &bull; (•, bullet).
Spacing and layout: &nbsp; (non-breaking space, prevents line break between two words), &ensp; (en space), &emsp; (em space), &thinsp; (thin space).
Currency and commerce: &copy; (©, copyright), &reg; (®, registered trademark), &trade; (™, trademark), &dollar; ($), &cent; (¢), &pound; (£, British pound), &euro; (€), &yen; (¥), &curren; (¤, generic currency).
Math and science: &plusmn; (±, plus-minus), &times; (×, multiplication), &divide; (÷, division), &ne; (≠, not equal), &le; (≤, less-or-equal), &ge; (≥, greater-or-equal), &deg; (°, degree), &micro; (µ, micro), &infin; (∞, infinity), &sum; (∑, summation), &radic; (√, square root), &frac14; (¼), &frac12; (½), &frac34; (¾).
Arrows and symbols: &larr; (←), &rarr; (→), &uarr; (↑), &darr; (↓), &harr; (↔), &check; (✓, check mark), &cross; (✗, cross mark), &star; (★).
Accented Latin characters (commonly needed for European names): &agrave; (à), &aacute; (á), &eacute; (é), &ntilde; (ñ), &ouml; (ö), &uuml; (ü), &ccedil; (ç), &oslash; (ø), &aring; (å).
UTF-8, Unicode, and When Raw Characters Beat Entities
The practical guidance for 2026 is straightforward: declare UTF-8 in your document head (<meta charset="UTF-8">), save your files as UTF-8, and write special characters directly in the source. The &copy; entity and the raw © character are functionally identical once parsed — but raw Unicode is shorter, more readable in source editors, more searchable with Ctrl+F, and avoids the named-entity compatibility issue with non-HTML contexts like SVG, XML, and template engines that may not decode named entities.
The cases where entities remain the better choice are specific. When your source files are processed by a system with uncertain encoding handling — older CMSes, legacy email systems, some XML pipelines — entities avoid encoding accidents. When you are writing HTML inside a JavaScript string or a JSON value that will later be injected into the DOM, entities help signal intent to the reader that the content is pre-escaped. When you are writing documentation about HTML itself, as in this article, entities are necessary to display the characters without the browser interpreting them as markup.
One common misconception is that entities improve SEO. Search engine crawlers parse HTML the same way browsers do — they decode entities before indexing text, so &amp; and & are indexed identically. Using entities does not help or hurt ranking. Another misconception is that entities are required for non-ASCII characters in URLs. They are not — URL encoding (percent-encoding) is a separate system used in href attributes, and HTML entities are not valid URL encoding. A correct link to a page with an ampersand in the query string uses URL-encoding in the href (%26) while the visible link text uses an HTML entity if needed.
HTML Entities and XSS: Security Implications of Improper Escaping
Cross-Site Scripting (XSS) is the most common web application vulnerability class, and improper HTML escaping is almost always the root cause. When user-supplied input is inserted into an HTML page without escaping the five structural characters, an attacker can inject <script> tags or event handler attributes that execute arbitrary JavaScript in the victim's browser. Stored XSS (injected content saved to a database and re-served to other users) is particularly dangerous because a single injection can affect every visitor to a page.
The escaping rules differ by insertion context. Inserting user text into HTML body content requires escaping <, >, and & at minimum. Inserting into an attribute value requires also escaping the quote character used to delimit that attribute — typically " for double-quoted attributes. Inserting into a JavaScript string context requires JavaScript string escaping, not HTML entity escaping — these are different operations and conflating them causes subtle vulnerabilities. Inserting into a CSS property value requires CSS escaping. Inserting into a URL query parameter requires percent-encoding.
The correct approach in every modern web framework is to use the framework's built-in templating with auto-escaping enabled, never concatenating raw user input into HTML strings manually. React, Vue, and Angular all escape dynamic content by default — the developer must explicitly opt out using mechanisms like dangerouslySetInnerHTML (React) to insert raw HTML. Server-side frameworks like Django, Jinja2, Laravel Blade, and Ruby on Rails ERB also auto-escape by default. The entity reference table and encoding rules above are useful background knowledge, but the implementation should always delegate to a battle-tested library rather than hand-rolling an escape function.
More in text tools
View all text tools guides →