HTML Encoding and XSS Prevention: A Developer's Guide

Cross-site scripting (XSS) has been on the OWASP Top 10 for as long as there has been a Top 10. It is the vulnerability that lets an attacker inject their own JavaScript into your page and run it in your users’ browsers. The single most effective defense against the most common form of XSS is also one of the simplest: HTML-encode untrusted data before you put it in the page. This article explains what HTML encoding is, which characters matter, and why encoding alone is not enough in every context.

What HTML encoding does

In HTML, several characters have special meaning. < starts a tag, > ends a tag, & starts an entity reference, and " and ' delimit attribute values. If you want to display these characters as literal text rather than have the browser interpret them as markup, you replace them with HTML entities:

Character	Entity
&	&
<	&lt;
>	&gt;
"	&quot;
'	&#39;

This process is also called escaping. When the browser encounters <, it renders a literal < rather than starting a tag. You can encode and decode these entities with the HTML Entity Encoder.

Why escaping prevents XSS

Suppose your page displays a search query back to the user:

<p>You searched for: USER_INPUT</p>

If USER_INPUT is fluffy kittens, the page is harmless. But if an attacker crafts USER_INPUT as <script>stealCookies()</script>, the browser interprets the <script> tag as real markup and executes the code — a classic reflected XSS attack.

If you HTML-encode the input first, the dangerous string becomes <script>stealCookies()</script>. The browser renders it as the literal text <script>stealCookies()</script> — visible to the user, but not executed. The attack is neutralized.

This is why escaping untrusted data on output is the foundation of XSS defense. Every time you insert data that came from a user, a database, or a third-party feed into an HTML document, escape it first.

The five characters that matter

For inserting text into an HTML element’s content (between <p> and </p>, for example), escaping five characters is sufficient: &, <, >, ", '. These are the characters that can break out of the text context and into markup. The HTML Entity Encoder escapes exactly these five.

Context is everything

The catch — and it is a big one — is that the right escaping depends on where the data is inserted. The five-character HTML escape is correct for element content, but it is not sufficient for every context:

Inside an HTML element

<div>USER_INPUT</div>

HTML-encode & < > " '. Safe.

Inside a quoted attribute

<input value="USER_INPUT">

HTML-encode & < > " ' (the quote that delimits the attribute is critical). Safe with the standard five.

Inside a URL attribute

<a href="USER_INPUT">link</a>

URL-encode the value first (with the URL Encoder), then HTML-encode the result. Otherwise an attacker can inject javascript:alert(1) as the href, which executes when clicked.

Inside a <script> block

<script>var data = "USER_INPUT";</script>

HTML encoding does not help here — the browser does not decode entities inside <script>. You must escape for JavaScript string context (backslash-escaping quotes and newlines) and ideally avoid putting untrusted data in script blocks at all. Put it in a data-* attribute and read it from the DOM instead.

Inside a style attribute or CSS

CSS has its own escaping rules. Avoid putting untrusted data in CSS at all; if you must, use CSS-string escaping.

Inside an event handler

<button onclick="doSomething('USER_INPUT')">

Like the script block, this is a JavaScript context. HTML encoding is insufficient. Avoid inline event handlers with untrusted data entirely.

The defense in depth

Escaping is the primary defense, but a robust XSS strategy layers several controls:

1. Escape on output, context-appropriately. This is the main defense and catches the vast majority of cases.
2. Use a templating engine that auto-escapes. Modern frameworks (React, Vue, Angular, Astro’s own templating) escape interpolated values by default. Use the framework’s escaping rather than rolling your own.
3. Use HTTPS. Prevents injection of malicious scripts in transit.
4. Set a strong Content Security Policy (CSP). A CSP that disallows inline scripts and restricts script sources makes even an injection much harder to exploit. This is your safety net when escaping fails.
5. Validate input. Reject data that is not in the expected format, but never rely on input validation alone for XSS — output escaping is what actually prevents execution.
6. Don’t accept arbitrary HTML from users. If you must (a comment system that allows some formatting), use a well-tested sanitizer like DOMPurify that allows only a safe subset of tags and attributes.

Markdown and HTML

Markdown is a common vector because it allows raw HTML passthrough by default. If you render user-submitted Markdown to HTML, an attacker can include a <script> tag inside the Markdown. Sanitize the rendered HTML with a library like DOMPurify before inserting it into the page. The Markdown Previewer renders Markdown for preview; if you ship that HTML to other users, sanitize it first.

HTML encoding vs URL encoding vs Base64

These three encodings solve different problems and are not interchangeable:

• HTML entity encoding makes text safe inside an HTML document. Use it for page content and quoted attributes.
• URL encoding (percent-encoding) makes text safe inside a URL. Use it for query parameters and path segments.
• Base64 encoding makes binary data safe inside a text channel. Use it for embedding images or transmitting binary — never for security.

Each is the right tool for its own job. Picking the wrong one leaves a vulnerability even when you remember to encode.

The summary

• Escape untrusted data every time you put it in a page. This is the cornerstone of XSS defense.
• Escape for the right context. HTML-encode for element content and quoted attributes; URL-encode for URLs; JavaScript-escape for script contexts; avoid untrusted data in script and style blocks.
• Use a framework that auto-escapes. Let the tool do the work.
• Layer a Content Security Policy. It is the safety net for when escaping fails.
• Sanitize any HTML you accept from users. Use DOMPurify, not a regex.

For experimenting with how escaping transforms a payload, run a string like <script>alert('xss')</script> through the HTML Entity Encoder and see the safe output — then build the habit of doing it everywhere untrusted data meets your page.