URL Encoding Explained

What a URL is allowed to contain

A URL is built from a small alphabet. The unreserved characters — letters A–Z and a–z, digits 0–9, and the four symbols hyphen (-), underscore (_), period (.) and tilde (~) — are always safe and never need encoding. Then there are the reserved characters, which have structural jobs inside a URL: the colon and slashes in "https://", the question mark that starts a query string, the hash that starts a fragment, and symbols like &, =, + and @ that separate parameters and user information.

Everything else must be encoded. That includes spaces, quotes, angle brackets, non-ASCII characters like é or 中, and control characters. If a character has no safe place in a URL, percent-encoding gives it one — and if a reserved character appears inside a value rather than in its structural role, it must be encoded too, or the URL will be parsed differently from what you intended.

How percent-encoding works

Percent-encoding replaces each unsafe byte with a percent sign followed by two hexadecimal digits representing the byte's value. A space is byte 0x20, so it becomes %20. An ampersand is 0x26, so it becomes %26. For characters outside ASCII, the text is first encoded as UTF-8 and then each byte is encoded separately: the letter é becomes the two bytes 0xC3 0xA9, written as %C3%A9.

Decoding reverses the process exactly, so encoding is lossless — you always get back the original text. It is also worth noting that encoding is defined per byte, not per character, which is why a single non-ASCII character can expand into several percent-encoded triplets. An encoder tool handles this automatically: paste text in, get the encoded form out, and decode it back to check the round trip.

hello world  ->  hello%20world
fish & chips ->  fish%20%26%20chips
café         ->  caf%C3%A9
100% sure    ->  100%25%20sure

Query strings: the + trap

The most common encoding surprise lives in query strings. When a browser submits a form using the application/x-www-form-urlencoded format, a space is encoded as a plus sign (+) rather than %20. So a search for "fish and chips" arrives at the server as q=fish+and+chips, and the server decodes + back to a space.

But in a URL path, a plus sign is just a plus sign — it is not decoded to a space. That means the same character means different things in different parts of a URL, and mixing them up is the single most frequent encoding bug. If you are building a query string by hand, encode spaces as %20 or let your HTTP library do the encoding for you; if you are reading a query value, use a parser that knows the form-encoding rules instead of decoding by hand.

What to encode and what to leave alone

The golden rule is to encode values, not whole URLs. Encode the user input that goes into a query parameter or a path segment, and leave the structure of the URL — the scheme, the slashes, the question mark, the ampersands between parameters — untouched. Encoding an entire URL turns "https://example.com/a b" into "https%3A%2F%2Fexample.com%2Fa%20b", which is no longer a usable link.

The mirror-image mistake is double encoding: encoding a value that is already encoded. If "%20" gets encoded again, the percent sign itself becomes %25, producing "%2520" — and the server decodes it once to "%20" instead of a space, so the value arrives wrong. Whenever you see %25 in a URL, double encoding is the first suspect. Encode each value exactly once, at the moment it enters the URL.

• Encode user input in query values and path segments.
• Never encode the whole URL — the ://, ?, & and = must stay as they are.
• Encode each value once; %25 in a URL usually means double encoding.
• In query strings, + means space; in paths, + is literal.

Encoding in practice

In practice, you rarely encode by hand. Browsers encode the address bar automatically, HTTP libraries encode parameters for you, and frameworks handle form data. Encoding becomes your problem in three situations: building URLs from user input, debugging a request that arrives garbled, and working with APIs that are strict about what they accept.

When a link breaks, the debugging steps are always the same. First, look at the raw URL: which characters are encoded and which are not? Second, check whether the value was encoded in the right context — path or query. Third, paste the value into an encoder and compare: if the tool's output differs from what your code produced, your code is encoding at the wrong layer or the wrong number of times. And remember that Base64 output, which often travels inside URLs, uses + and / — if you need it in a URL, use the URL-safe variant or percent-encode it.