Developer

What Is URL Encoding (Percent-Encoding)?

Dev Nexus4 min read

A plain-English guide to percent-encoding: what it is, which characters are reserved or unsafe, and why every query value needs it.

Every time you click a link with a %20 or a %3D in it, you are looking at URL encoding. Also called percent-encoding, it is the quiet mechanism that lets arbitrary text — spaces, punctuation, accented letters, entire other URLs — ride safely inside an address bar or an API request.

This post explains what percent-encoding actually is, which characters trigger it, and why the values in a query string almost always need to be encoded before you send them.

The Problem

URLs are not free-form text. The URL standard permits only a small alphabet: the letters A-Z and a-z, the digits 0-9, and a few symbols like -, ., _, and ~. Everything else is either forbidden or has a special structural meaning.

That causes real breakage. A search for black & white becomes a query where the & is read as a separator between two parameters, so the server only sees black. A redirect target with a ? in it truncates the outer query. A name like José may not survive the trip at all. The symptoms are broken links, dropped parameters, and mysterious undefined responses — all because a value contained a character the URL syntax could not tolerate.

The Solution

Percent-encoding solves this by replacing each problem character with a % followed by its byte value in two hexadecimal digits. A space becomes %20, an ampersand becomes %26, a question mark becomes %3F. For non-ASCII text the character is first encoded as UTF-undefined bytes, then each byte is percent-escaped — so é becomes %C3%A9.

Characters fall into three buckets. Unreserved characters (letters, digits, and - . _ ~) never need encoding. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have structural meaning and must be encoded when they appear inside a value rather than as syntax. Everything else — spaces, control characters, and non-ASCII — is unsafe and must always be encoded.

The URL Encoder applies these rules for you in the browser, so you can encode a value correctly without memorising the hex table. Because it runs locally, nothing you paste is uploaded.

Step-by-Step Guide

1
Identify what is a value and what is structure
In https://example.com/search?q=black & white, the ? and = are structure and the text after q= is a value. Only the value needs encoding. Confusing the two is where most encoding mistakes begin.
2
Encode each unsafe or reserved character
Walk the value and replace anything outside the unreserved set. black & white becomes black%20%26%20white. The space is unsafe (%20) and the ampersand is reserved (%26).
3
Handle non-ASCII as UTF-8 bytes
For characters beyond ASCII, encode the UTF-undefined byte sequence. José becomes Jos%C3%A9 — one escape per byte. Modern encoders do this automatically.
4
Assemble the final URL
Drop the encoded value back into the query string: https://example.com/search?q=black%20%26%20white. Now the & is data, not a separator, and the server receives the full phrase.
5
Verify by decoding
Paste the finished URL back into the tool and decode it. If you get your original value back cleanly, the encoding is correct. If you see leftover %25 sequences, it was encoded twice.

Common Mistakes

Encoding the whole URL as one value
Running an entire URL through component-style encoding escapes the ://, /, and ? that hold it together, producing a string that is no longer a working URL. Encode values, not structure.
Forgetting to encode reserved characters in values
A value can legitimately contain &, =, or #. Leaving them raw makes the URL parser treat them as syntax, silently dropping or splitting your data. Always encode reserved characters inside a value.
Assuming a space is always +
The + shorthand for a space only applies to application/x-www-form-urlencoded form data. In a normal path or query, a space is %20. Using + in the wrong place can leave a literal plus sign in your value.
Double-encoding
Encoding a value that was already encoded turns %20 into %2520. This usually happens when a value passes through two layers that both encode. Encode exactly once at the boundary that needs it.

Frequently Asked Questions

Is URL encoding the same as percent-encoding?

Yes. "URL encoding" and "percent-encoding" are two names for the same mechanism: replacing characters with a `%` followed by two hex digits so they can appear safely in a URL.

Which characters must always be encoded?

Spaces, control characters, and any non-ASCII text must always be encoded. Reserved characters like `& = ? # /` must be encoded when they appear inside a value rather than as URL structure.

Why does é turn into %C3%A9?

Non-ASCII characters are first converted to their UTF-8 byte sequence, then each byte is percent-encoded. The letter é is two bytes in UTF-8 (0xC3 0xA9), so it becomes %C3%A9.

Do I need to encode letters and numbers?

No. Letters, digits, and the unreserved symbols `- . _ ~` are always safe and are never encoded. Only reserved and unsafe characters are escaped.

How do I check if a value is already encoded?

Decode it. If it contains `%` followed by two hex digits and decoding produces readable text, it was encoded. If decoding yields more `%25` sequences, it was encoded more than once.