Why some characters can't appear literally in a URL
A URL uses certain characters for its own structure — & separates query parameters, ? marks where the query string begins, = separates a parameter name from its value, and a space isn't technically valid in a URL at all. If a value you want to include (say, a search term) itself contains one of these characters, it needs to be encoded first, or it would be misread as part of the URL's structure rather than as literal data.
How percent encoding works
Each character to be encoded is replaced with a % followed by its byte value in hexadecimal — a space becomes %20, an ampersand (&) becomes %26, a question mark (?) becomes %3F, and an equals sign (=) becomes %3D. Letters, digits, and a small set of "safe" punctuation marks are left unencoded, since they don't conflict with the URL's own structural characters.
A worked example
Encoding "hello world & more?=yes" produces "hello%20world%20%26%20more%3F%3Dyes" — every space, ampersand, question mark, and equals sign is replaced with its percent-encoded form, while the letters pass through unchanged. Decoding that string exactly recovers the original text — like Base64, percent encoding is fully reversible with no data loss.
Why this matters beyond just "special" characters
Percent encoding isn't only for punctuation — any character outside the URL's safe ASCII set, including non-English letters, accented characters, and emoji, gets percent-encoded as well (typically as their UTF-8 byte sequence, encoded byte by byte). This is why a URL containing non-English text often looks like a long string of %XX sequences when you inspect the raw address bar or a server log, even though the browser usually displays the readable version to the user.