A URL carries a fixed set of characters with structural meaning. Percent encoding is how you send text through the address without the text rewriting the address.
Why a slash inside a value breaks the address
Put path/to/file into a query parameter as raw text and the server sees the slash as part of the address structure. The same applies to &, which ends one parameter and starts the next, and to #, which cuts everything after it into a fragment the server never receives. Percent encoding replaces each of those bytes with a % followed by two hex digits, so & arrives as %26 and gets read as data rather than punctuation.
The tricky part is not the encoding itself. It is picking the correct rule set, because the four in common use disagree about which characters count as structure.
Which rule set fits your case
| Rule set | Leaves alone | Use it for |
|---|---|---|
ComponentencodeURIComponent | Letters, digits, - _ . ! ~ * ' ( ) | One parameter value, one path segment, anything going inside a larger address. |
Whole URLencodeURI | All of the above plus : / ? # [ ] @ $ & + , ; = | An address already assembled, where you want spaces and accents fixed without splitting the structure. |
Form dataapplication/x-www-form-urlencoded | Same as component, except a space becomes + | POST bodies and query strings built by an HTML form or a legacy API. |
| RFC 3986 strict | Letters, digits, - _ . ~ only | OAuth 1.0 signatures, AWS request signing, anywhere a signature is computed over the encoded string. |
Getting this wrong produces a bug with no error message. Encode a full address with the component rule and the server receives one long string where a path used to be. Encode a parameter value with the whole-URL rule and a stray & inside the value silently splits it into two parameters, with the second one carrying whatever followed.
The space problem
A space encodes as %20 in a path and as either %20 or + in a query string. Both readings are legal, which is why the two exist. A server parsing a query string turns + back into a space, and a server parsing a path does not, so a + in a filename comes through as a literal plus. When a filename with spaces arrives mangled, the mismatch between these two rules is usually the reason.
Double encoding, and how to recognize it
Run a string through an encoder twice and the percent signs get encoded too. %20 becomes %2520, because % itself encodes to %25. Once you know the pattern, %25 sitting in front of what looks like another escape is the signature.
- A framework already encoded it. Most HTTP clients and routers encode query parameters on the way out, so hand-encoding first produces a doubled string.
- A value passed through a redirect. A destination stored inside a
redirect_urigets encoded once as a value, then again when the wrapper itself is encoded. - Decode twice to confirm. Paste the string, decode, then press the swap button to send the result back and decode again. If the second pass produces readable text, it was double encoded.
The swap button exists for this. It moves the result into the input and flips the direction, so peeling layers takes one click each instead of a copy and a paste.
What the round-trip check tells you
After every run, the tool applies the opposite operation to its own output and compares the result against what you typed. A green state means the transformation is lossless under the selected rule. A warning means the two disagree, which happens on legitimate input more often than people expect: decoding a+b under form rules gives a b, and encoding that back gives a+b again, so a literal plus sign in the original never survives.
Treat the warning as information, not a failure. It marks the cases where the byte you started with is no longer recoverable from the string you are holding.
Where this tool stops
Everything runs in the page with the browser's own encoder, so nothing leaves your tab. That also draws the limit. The tool works on text, not on network behavior: it will not fetch an address, follow a redirect, or tell you whether the server on the other end accepts the encoding you picked. Some servers normalize %2F back to a slash before routing, and no amount of correct encoding on your side changes that.
It also treats input as a single string rather than a parsed address. If you need to see a URL split into host, path, and individual parameters, or you are unwrapping a redirect to find the address hiding inside it, the Un Google Link tool handles the structural side. For very large inputs, encoding is a per-character operation, so a multi-megabyte paste will stall the tab before it finishes.
Encoding is not escaping for HTML or SQL. A percent-encoded string dropped into a page still needs HTML escaping, because < survives encodeURI untouched. Encoding decides how a value travels through an address. It says nothing about how the value behaves once something else parses it.
