HTML Encoding vs URL Encoding: What's the Difference?

Both HTML encoding and URL encoding transform special characters into an escaped format — but they exist for entirely different reasons, produce different output, and need to be applied in different contexts. Confusing them is a source of broken pages, mangled query strings, XSS vulnerabilities, and mysterious & strings appearing in your rendered HTML.

This guide explains exactly what each encoding does, why it exists, and how to apply the right one in the right situation. Both have free browser-based tools on DevToolShack: HTML Encoder/Decoder and URL Encoder/Decoder.

HTML Encoding (HTML Entity Encoding)

HTML encoding converts characters that have special meaning in HTML into their entity equivalents — safe representations that the browser renders as the character itself rather than interpreting as markup.

The characters that must be HTML-encoded in text content are:

If a user submits the text <script>alert('xss')</script> and you render it in a page without HTML encoding, the browser executes it as JavaScript. If you HTML-encode it first, the browser renders it as visible text: <script>alert('xss')</script>. This is why HTML encoding of user-supplied content is a fundamental XSS prevention technique.

Named Entities vs Numeric Entities

HTML entities come in two forms. Named entities use a short name: <, &, © (©), — (—). Numeric entities use the Unicode code point, either decimal (©) or hex (©). Both render identically. Named entities are more readable; numeric entities work for any Unicode character, including those without named entity equivalents.

When to Use HTML Encoding

Use HTML encoding any time you're inserting user-controlled or dynamic text into an HTML document — in element content, in attribute values, in data attributes. In server-side templating languages, this is usually handled automatically by the template engine (Twig, Blade, Jinja2 all escape by default). In JavaScript, element.textContent = value is safe; element.innerHTML = value requires encoding first.

URL Encoding (Percent Encoding)

URL encoding converts characters into a percent-followed-by-hex-code format so they can be safely included in a URL without breaking its structure. A URL has specific reserved characters that delimit its parts: / separates path segments, ? starts the query string, & separates query parameters, = separates keys from values, and # starts a fragment. If any of these characters appear in your data — say, a search query containing an ampersand — they must be percent-encoded so they're treated as data, not as URL structure.

Original:  Hello World & "Goodbye"
URL encoded: Hello%20World%20%26%20%22Goodbye%22

Original query: q=C++ programming
URL encoded:    q=C%2B%2B%20programming

For a full explanation of which characters require encoding and how the rules differ between path segments and query strings, see URL Encoding Explained: Why Your URLs Break and How to Fix Them.

encodeURI vs encodeURIComponent in JavaScript

JavaScript has two URL encoding functions and they encode different character sets:

// encodeURI — encodes a complete URL; preserves URL structure characters
encodeURI('https://example.com/search?q=hello world&lang=en');
// "https://example.com/search?q=hello%20world&lang=en"
// Note: & and = are NOT encoded — they're valid URL structure

// encodeURIComponent — encodes a single value; encodes ALL special chars
encodeURIComponent('hello world&lang=en');
// "hello%20world%26lang%3Den"
// Note: & and = ARE encoded — they're treated as data, not structure

The rule is: use encodeURIComponent for individual parameter values; use encodeURI only for encoding a complete URL that already has proper structure. In practice, encodeURIComponent is the one you reach for most often, since you're usually constructing query strings from dynamic values.

The modern URLSearchParams API handles this correctly and is generally preferable to manual encoding:

const params = new URLSearchParams({
  q: 'C++ programming',
  lang: 'en',
  tags: 'web&mobile'
});
console.log(params.toString());
// "q=C%2B%2B+programming&lang=en&tags=web%26mobile"

The Key Differences Side by Side

Common Mistakes

Double-encoding

If you HTML-encode a value and then URL-encode the result, or vice versa, you get double-encoded output. A URL already containing %26 that gets URL-encoded again becomes %2526 — which decodes to the literal string %26 rather than the original &. Always encode once, at the correct layer, using the correct method.

Using HTML encoding in URLs

An & in a URL is wrong. The HTML entity & in an href attribute is how you represent a literal & in the HTML source — but once the browser parses the attribute, the actual URL it navigates to contains a raw &, which properly separates query parameters. Using %26 in the query string is the URL encoding; & is the HTML attribute encoding that wraps it in the HTML source. Both can be correct in their own context, but they're doing different jobs.

Not encoding user input in URLs

If you construct a URL by concatenating user-supplied strings without encoding them, a user can inject query parameters, path segments, or even redirect to a different host. Always encode values with encodeURIComponent before inserting them into URLs.

Base64: The Third Encoding You'll Encounter

Base64 is sometimes confused with URL encoding because it also transforms content into ASCII-safe characters. But Base64's purpose is different: it encodes binary data (or any data) into a character set that can safely travel through text-based channels like email or HTTP headers. It's not about making URLs safe or preventing HTML injection — it's about making arbitrary bytes representable as text. For a full explanation of when Base64 is appropriate and when it's not, see Base64 Encoding Explained: What It Is and When to Use It.