Look at your address bar after searching for anything with a space in it and you will see %20 where the space used to be. That transformation is URL encoding, also called percent-encoding, and it is one of the oldest pieces of plumbing on the web. It is defined in RFC 3986, the specification for URI syntax, and every browser, server, and HTTP library relies on it constantly.
The problem it solves
A URL is two things at once: structure and data. The structure is made of separator characters, where ? starts the query, & separates parameters, = splits a name from its value, and # begins the fragment. The data is everything you put between those separators. The moment your data contains one of the separator characters, the string becomes ambiguous.
Imagine a search for the term fish & chips. Written naively into a query string it becomes:
https://example.com/search?q=fish & chips&page=2A server reading that sees three parameters: q=fish, a nameless chips, and page=2. The ampersand that was part of your data has been read as structure, and the space is not even legal in a URL. Percent-encoding removes the ambiguity:
https://example.com/search?q=fish%20%26%20chips&page=2Each unsafe character has been replaced by a percent sign followed by the value of its byte in hexadecimal: %20 for the space, %26 for the ampersand. The receiving server decodes them after it has split the URL apart, so the structure stays intact and the data arrives untouched.
What never needs encoding
RFC 3986 defines a small set of characters that are always safe, called the unreserved set: the letters A to Z in both cases, the digits 0 to 9, and the four symbols hyphen, underscore, period, and tilde. Everything outside that set either has a job inside the URL or is forbidden, so as data it must be encoded. This is why encoded URLs are so recognizable: anything interesting in them becomes a run of percent signs.
Characters beyond ASCII
Percent-encoding works on bytes, not on characters, and that distinction matters as soon as text leaves English. The letter é does not have a single agreed byte; in UTF-8, the encoding of the modern web, it is two bytes, which encode as %C3%A9. An emoji can be four bytes, so one visible character becomes four percent-escapes. Decoding has to reassemble those bytes with the same character set that produced them, which is exactly where a lot of real-world breakage comes from.
Where you will meet it
- Query parameters carrying search terms, filters, and free text.
- Redirect and callback URLs in OAuth flows, where an entire URL travels inside another URL and must be fully encoded to survive.
- Tracking links, where UTM values often contain spaces and punctuation.
- REST APIs, where identifiers with slashes or colons appear in paths.
- Anything you paste into curl, a webhook configuration, or a spreadsheet of URLs.
The one habit that prevents most bugs
Encode values, not URLs, and encode them exactly once, at the moment you place them into the string. Building a URL out of already-encoded fragments, or encoding the finished URL a second time for luck, produces the double-encoding and broken-separator bugs that fill bug trackers. If you are unsure what state a string is in, decode it until it stops changing, then encode once.