Why URLs Need Encoding at All
A URL is a compact instruction with structure baked into specific characters: the ? starts the query string, & separates parameters, = joins a name to its value, / divides path segments, and # marks a fragment. A handful of other characters are simply not permitted in a URL at all — most famously the space, which in many contexts would be read as the end of the address.
That creates a problem: what if your data genuinely contains one of those characters? A search for "rock & roll" or a filename with a space in it would shatter the URL's structure, because the browser would read the & as a separator and the space as a terminator. URL encoding is the escape hatch — a way to include any character as ordinary data without it being mistaken for structure. For where the query string sits in the wider address, the URL, hostname, and domain breakdown shows the full anatomy.
How Percent-Encoding Works
The mechanism is mechanical and simple. Take the character you need to encode, look up its byte value in hexadecimal, and write a percent sign followed by those two hex digits. That is the whole scheme — which is why it is also called percent-encoding.
| Character | Encoded as |
|---|---|
| space | %20 |
/ | %2F |
? | %3F |
& | %26 |
= | %3D |
# | %23 |
% | %25 |
Notice the percent sign itself must be encoded as %25 — otherwise the browser could not tell a literal percent from the start of an encoded sequence. So the phrase rock & roll in a value becomes rock%20%26%20roll: the spaces and the ampersand are all neutralised into harmless data.
Reserved, Unreserved, and Everything Else
Not every character needs this treatment. The standard sorts characters into groups:
- Unreserved characters never need encoding: the letters A–Z and a–z, the digits 0–9, and the four symbols
-_.~. These are always safe to write literally. - Reserved characters have a structural job —
/ ? # [ ] @ ! $ & ' ( ) * + , ; =. They may appear unencoded when used as structure, but must be encoded when they are part of a value. - Everything else — accented letters, characters from other writing systems, emoji — is first converted to its UTF-8 bytes, and each byte is then percent-encoded. This is why a single emoji can expand into several
%sequences: it is more than one byte.
One special case trips people up: in the query string of a submitted form, a space is frequently encoded as a + rather than %20. This comes from the older form-encoding rules (application/x-www-form-urlencoded) and is why you sometimes see both forms in the wild. Both decode back to a space; they just come from slightly different traditions.
Where Encoding Happens — and Where It Goes Wrong
Most of the time you never encode anything by hand. The browser encodes a URL when you submit a form or click a link, and programming languages provide functions to do it. In JavaScript the two you will meet are encodeURI and encodeURIComponent, and confusing them is a classic bug. encodeURI is for an entire URL and deliberately leaves the structural characters like / ? & alone. encodeURIComponent is for a single value you are about to drop into a URL, and it encodes those characters too — so they cannot be misread as delimiters. The rule of thumb: use encodeURIComponent on each individual query value, and never on the whole address.
Get it wrong and you see double-encoding — a value encoded twice, so a real space (%20) becomes %2520 (the % itself got re-encoded to %25). The link then arrives at the server with a literal %20 in the data instead of a space, and searches or filenames silently fail to match. When a URL looks like it is stuttering in percent signs, double-encoding is almost always the cause.
Encoding Is Not Security
It is worth being clear about what URL encoding does not do. It is a formatting convention, not a secret code — anyone can decode %20 back to a space instantly, and the result is exactly as readable as before. It hides nothing and protects nothing. Confusing it with encryption or hashing leads to the dangerous mistake of putting sensitive data in a URL and assuming the encoding shields it. It does not: anything in a URL is visible in browser history, server logs, and the Referer header. Encoding only makes characters safe to carry; keeping data private is an entirely separate job.
Frequently Asked Questions
What is URL encoding?
A way of representing characters in a URL that would otherwise be unsafe or have special meaning. Each such character becomes a percent sign followed by its two-digit hexadecimal byte value — a space becomes %20. It lets URLs carry spaces, symbols, and non-English text without breaking.
Why does a space become %20 in a URL?
Raw spaces are not allowed in URLs, since a space can mark the end of the address. Percent-encoding replaces it with %20 — the percent sign plus the hex value of the space character. In a submitted form's query string, a space is often encoded as a plus sign instead.
What characters need to be URL encoded?
Reserved characters with a structural role — / ? # & = and the space — when they appear inside a value rather than as a delimiter. Unreserved characters (letters, digits, and - _ . ~) never need it. Non-ASCII characters like accented letters or emoji are encoded as their UTF-8 bytes.
What is the difference between encodeURI and encodeURIComponent?
Both percent-encode text but protect different characters. encodeURI is for a whole URL and leaves structural characters like / ? & intact; encodeURIComponent is for a single value and encodes those too, so they cannot be mistaken for delimiters. Use encodeURIComponent for individual query values.
Is URL encoding the same as encryption?
No. URL encoding is a reversible formatting scheme anyone can decode — it hides nothing and provides no security. Its only job is to make characters safe to transmit in a URL. Encryption deliberately conceals data so it cannot be read without a key.