HTML entities vs URL encoding: what is the difference
Tools Nimbus is a free, no-signup developer toolkit that runs entirely in your browser, so your data is never uploaded to a server. HTML entities and URL encoding both escape special characters, but for different places: HTML entities such as < keep characters safe inside markup, while URL percent-encoding such as %26 keeps them safe inside a link or query string. Apply each with the HTML Entity Encoder and Decoder and the URL Encoder and Decoder.
Last updated June 2026
Same idea, two different contexts
Both schemes do the same broad job: they replace characters that would otherwise be misread with a safe stand-in. The confusion comes from treating that as one problem when it is really two. An HTML parser and a URL parser care about completely different characters and follow completely different rules, so the escape that fixes one will not fix the other. The question that settles almost every case is simple: where is this value about to live? If it is going into the text or attributes of an HTML page, it needs HTML entities. If it is going into a link, a query string, or form data, it needs URL encoding.
Side by side
| Property | HTML entity encoding | URL percent-encoding |
|---|---|---|
| Protects | HTML document structure | Links and query strings in transport |
| Defined by | The HTML specification | RFC 3986 (percent-encoding) |
| Encodes an ampersand as | & | %26 |
| Encodes a space as | Usually nothing (or for a hard space) | %20 (or + in a query) |
| Syntax | &name; or &#nn; | %XX hex of UTF-8 bytes |
| Applied in | Page text, attribute values | URL paths, query params, form bodies |
| Reversible without a key | Yes, by anyone | Yes, by anyone |
| Provides secrecy | No | No |
HTML entities: keeping characters out of the markup
HTML has a handful of characters that are structural. The less-than sign starts a tag, the ampersand starts an entity, and double or single quotes delimit attribute values. If any of those appear literally where the parser expects markup, the page breaks or, worse, an attacker can inject a tag. HTML entity encoding solves this by swapping each one for a named entity like < for the less-than sign or a numeric entity like <. The browser renders the original character but never treats it as structure. This is why escaping untrusted input before it touches a page is a primary defence against cross-site scripting. You can see exactly what the escaped output looks like, named or numeric, in the HTML Entity Encoder and Decoder, which also decodes entities back to plain text.
URL encoding: keeping characters in the link
A URL has its own set of reserved characters. The question mark separates the path from the query, the ampersand separates query parameters, the hash starts a fragment, and the slash separates path segments. Spaces and many non-ASCII characters are not allowed at all. URL percent-encoding replaces each problem character with a percent sign and the hexadecimal value of its UTF-8 bytes, so a space becomes %20 and an ampersand inside a value becomes %26. That lets you carry a value such as a search phrase or another URL inside a query string without it being misread as structure. Encode a value and watch the bytes appear in the URL Encoder and Decoder, or decode a messy %-laden string back to readable text.
The classic mistake: using the wrong one
The output of both schemes can look similar enough that people reach for whichever they remember. The failure mode is quiet: the value often appears to work, then breaks on an edge case. Put a percent-encoded %3C into HTML text and the page shows the literal characters %3C instead of escaping a tag, because the HTML parser does not understand percent-encoding. Put a raw ampersand into a query string and everything after it is read as a new parameter. Worst of all, using HTML entities where you needed URL encoding can leave an injection hole open because the dangerous character was never actually neutralized for the right parser.
When you genuinely need both
Sometimes a single value passes through two contexts and needs both encodings, layered in order. A common example is a link whose href contains a query string and is printed inside an HTML page. First URL-encode the query value so the link is well-formed, then HTML-encode the whole attribute so characters like the ampersand between parameters do not break the markup. The order matters: encode for the innermost context first, then the outer one. The principle that keeps this straight is to encode once at each boundary, for the parser on the other side of that boundary, and never to double-encode by habit, which produces artefacts like &amp; or %2520.
How to choose in one line
Ask where the value is about to be read. Markup gets HTML entities; URLs get percent-encoding; a value crossing both gets each in turn. Neither scheme hides anything, so if your goal was secrecy you wanted encryption or hashing instead, which is covered in encoding vs encryption vs hashing. For a deeper look at one transport-safe encoding, see Base64 vs Base64URL, and browse the full set of tutorials on the Tools Nimbus guides index.