The five characters that actually need escaping
As covered in the Complete Guide to HTML Entities, only five characters carry structural meaning in HTML and need mandatory escaping: <, >, &, ", and '. Everything else can typically appear as a literal UTF-8 character in a modern, correctly-declared document.
Input: <script>alert(1)</script>
Escaped: <script>alert(1)</script>
The escaped version displays as harmless visible text; the unescaped version, inserted directly into a page, executes as a real script tag.
Why the exact escaping rule depends on context
This is the detail that trips people up: which characters need escaping — and how — differs depending on where the value is being inserted:
- Inside HTML body text: escape
<,>,&. - Inside an HTML attribute value: also escape the quote character matching whichever the attribute uses (
"or'). - Inside a
<script>block: HTML entity escaping doesn't apply the same way — content there needs JavaScript string escaping instead, since HTML entities aren't decoded within script content. - Inside a URL: needs percent-encoding (see Complete Guide to URL Encoding), an entirely different escaping mechanism from HTML entities.
Applying the wrong context's escaping rule — say, HTML-entity-escaping a value destined for a URL — doesn't just fail to protect against injection, it can also produce broken or incorrect output.
Why templating engines escape by default
Every mainstream templating system (React's JSX, Vue templates, Django templates, Handlebars, etc.) automatically HTML-escapes interpolated values by default — this is a deliberate security default, not an accident. The moment you explicitly bypass that default (dangerouslySetInnerHTML in React, |safe in Django/Jinja2, v-html in Vue), you take on full personal responsibility for ensuring the content is safe — usually because it's been through a dedicated sanitization library, not just manual escaping, since content meant to include some real HTML (like user-submitted rich text) needs more than simple escaping to stay both functional and safe.
Common mistakes
- Escaping only in one context and assuming it covers every context. Body-text escaping doesn't protect an attribute value or a
<script>block — check what context the value actually lands in. - Bypassing a templating engine's default escaping "just this once" without a specific sanitization plan. This is exactly how a stored XSS vulnerability gets introduced, often unnoticed until exploited.
- Confusing HTML escaping with URL encoding. They solve different problems for different contexts and aren't interchangeable — see Complete Guide to URL Encoding.
FAQ
Is escaping the same regardless of where a value is inserted in HTML?
No — body text, attribute values, <script> blocks, and URLs each have different escaping rules; applying the wrong one can fail to protect against injection or produce broken output.
Why do frameworks like React escape values by default?
Because unescaped user input rendered directly into HTML is the core mechanism behind XSS attacks — escaping by default is a deliberate, safer starting point that developers must consciously opt out of when needed.
Is it ever safe to render raw, unescaped HTML from user input?
Only after it's been processed by a dedicated HTML sanitization library (not just manual escaping) designed to allow safe markup while stripping dangerous elements and attributes — never render untrusted raw HTML directly.
Escape and decode HTML entities instantly with the HTML Entities tool — entirely in your browser.