What is URL Encoding?

URL encoding converts characters that are not allowed or are meaningful in a URL into a format that can be transmitted without changing the URL's structure. Each unsafe character is replaced by % followed by two hex digits representing the character's UTF-8 byte value.

A space is %20 (or + in form submissions), an ampersand is %26, a slash is %2F, and the letter é becomes %C3%A9 in UTF-8. The result is a string that contains only unreserved characters — letters, digits, hyphens, periods, underscores, and tildes — plus the escape sequences, which makes it safe to embed anywhere in a URL.

The URI specification defines two sets of characters. Reserved characters like /, ?, &, =, and # carry structural meaning — they delimit the scheme, host, path, and query components. If your data contains any of these, the server cannot tell whether you meant them as syntax or as literal content.

Unsafe characters add a second problem: spaces and control characters get stripped or mangled by browsers, proxies, and mail clients in transit, and non-ASCII characters have no guaranteed byte representation. Encoding eliminates both issues by reducing everything to plain ASCII that every system handles identically.

Percent-encoding works byte by byte. Take the string "a b". The space character is byte 0x20 in UTF-8, so it becomes %20 and the whole string becomes "a%20b". For multi-byte characters like the euro sign (€), which is three UTF-8 bytes (0xE2, 0x82, 0xAC), each byte is encoded separately, producing %E2%82%AC.

Decoding is the reverse: every %XX sequence is replaced with the byte XX, and the resulting byte stream is interpreted as UTF-8. Browsers encode URLs automatically as you navigate, and every programming language exposes encode/decode functions — encodeURIComponent in JavaScript, urllib.parse.quote in Python, URLEncoder in Java — so you rarely have to do it by hand.

Query parameters are the everyday case. A search URL like /search?q=hello world&page=2 would be ambiguous — the space could break parsing — so it is encoded as /search?q=hello%20world&page=2. The same applies to parameter values containing & or =, which would otherwise be read as additional parameters.

HTML forms use URL encoding natively: submitting a form with a space in a text field produces application/x-www-form-urlencoded data where spaces become +. API requests embed encoded payloads in URLs and POST bodies, and file names with non-ASCII characters are encoded when referenced in links. Every redirect URL that carries a return path must encode that path, or the return trip will break.

Both convert data into a safe text format, but they solve different problems. URL encoding keeps the data human-readable — "a%20b" clearly decodes to "a b" — and is designed to preserve the structure of the URL around the data. It encodes only what must be encoded, leaving the rest intact.

Base64 encodes everything, turning arbitrary binary data into an opaque 64-character alphabet that expands it by about 33%. Base64 is the right choice when you need to embed binary content — an image, a file, a signature — in a text channel like JSON or a data URL. URL encoding is the right choice when you need to embed human-readable text, like a search query or a slug, into a URL. Note that Base64 output often contains +, /, and =, which is why Base64URL exists for safe use inside URLs.