URL Encoding Explained: Why Spaces Become %20

Copy a link to a search result or a file with a space in its name and you will often see strange sequences like %20, %2F or %C3%A9. This is URL encoding, also called percent-encoding. It is how browsers and servers make sure every character in a web address survives the trip intact.

Why URLs need encoding

The rules for URLs allow only a limited set of characters: the letters A–Z and a–z, digits 0–9, and a few symbols such as -, ., _ and ~. Some other symbols are allowed but have a special job:

/ separates parts of the path.
? starts the query string.
& separates parameters, and = separates a name from its value.
# starts the fragment, the part that jumps to a section of the page.

So what happens if the value you want to send contains one of these characters, or a space, or a letter like é or ß? Without encoding, the server would misread it. A search for salt & pepper would be cut off at the &, and the rest would look like a new parameter.

How percent-encoding works

Each unsafe character is converted to its bytes in UTF-8, and each byte is written as a percent sign followed by two hexadecimal digits:

A space is byte 32, or 20 in hex, so it becomes %20.
& becomes %26, / becomes %2F, and ? becomes %3F.
é takes two bytes in UTF-8, so it becomes %C3%A9.
An emoji takes four bytes, so it becomes four percent-codes in a row.

Decoding reverses the process. Paste any encoded link into the URL Encode / Decode to read it as normal text.

Plus signs and spaces

You will sometimes see spaces written as + instead of %20. That comes from the older format used by HTML forms (application/x-www-form-urlencoded), where + means a space in the query string. In the path of a URL, though, + is just a plus sign. To be safe, encode spaces as %20 and a real plus sign as %2B. Many “my plus sign disappeared” bugs come from this difference.

Encoding a whole URL versus one value

There are two different jobs, and mixing them up causes most problems:

Encoding a single value, such as a search term or a redirect address you are putting inside a parameter. Here you want every special character encoded, including /, ?, & and =, so the value can’t break the URL around it. In JavaScript this is encodeURIComponent.
Cleaning up a whole URL that may contain spaces or accented letters. Here you want to keep the structural characters as they are and only encode the rest. In JavaScript this is encodeURI.

For example, to pass https://example.com/a?b=1 as a next parameter, it must be fully encoded: ?next=https%3A%2F%2Fexample.com%2Fa%3Fb%3D1. If it isn’t, the server sees b=1 as a separate parameter of your own URL.

Double encoding

If text is encoded twice, the percent signs themselves get encoded. A space becomes %20 the first time and %2520 the second time, because % is encoded as %25. When you see %25 followed by two hex digits in a link, it has almost certainly been encoded twice. Decode it once, check the result, and decode again if needed. The fix in code is to encode each value exactly once, at the moment you build the URL.

URL encoding versus other encodings

It is easy to confuse URL encoding with similar schemes:

HTML entities such as & and < make text safe inside HTML, not inside URLs. Use the HTML Entity Encode / Decode for those. A link inside an HTML page may need both: URL-encode the value, then HTML-escape the & characters in the attribute.
Base64 turns binary data into text. It is used for data URIs and tokens, not for ordinary URL parameters. See what Base64 is or try the Base64 Encode.

None of these is encryption. Anyone can decode them, so never rely on encoding to hide private information in a link.

Quick reference

Space: %20 (or + in form query strings)
&: %26 · =: %3D · ?: %3F
/: %2F · #: %23 · %: %25
+: %2B