Percent-encoding exists because URLs have a grammar. Certain characters are structural — the slash separates path segments, the question mark starts the query, the ampersand separates parameters — and any time one of those characters needs to appear as data rather than as punctuation, it has to be disguised.
Get the disguise wrong and you get bugs that only affect some users, which are the worst kind. This piece covers the distinctions that actually cause problems, and where a URL Encoder and Decoder saves you from them.
Component or whole URL: the choice that matters
This is the distinction that causes most real-world breakage, and it comes down to one question: are you encoding a value that will go inside a URL, or a complete URL that needs cleaning up?
Component encoding escapes the reserved characters too — slash, question mark, ampersand, equals, hash. Use it for a search term, a filename, a redirect target, anything that is data rather than structure. This is what encodeURIComponent does in JavaScript.
Whole-URL encoding assumes the address is already structured correctly and only fixes genuinely illegal characters such as spaces and accented letters. Slashes and ampersands are left alone because they are doing their job. This is encodeURI.
The classic bug is using the second where you meant the first. You build a redirect like /go?to=https://example.com/a?b=1&c=2, encode the whole thing, and the target’s query string silently becomes part of your own. It works in testing, because your test URL had no ampersand in it.
Why a space is sometimes %20 and sometimes a plus
Two different conventions collided historically and both survived.
- In the path, a space must be
%20. A plus sign there is a literal plus sign and nothing else. - In the query string, the older HTML form-encoding convention writes a space as
+, and most servers accept either.%20is also valid there.
The practical rule: use %20 everywhere and you will never be wrong. The trouble starts when decoding, because a decoder has to know which convention produced the string. Ours converts plus signs back to spaces when decoding in component mode, which is right for form data and wrong if the plus was meant literally — a genuinely ambiguous case with no correct universal answer.
If you have a literal plus that must survive, encode it as %2B before it ever reaches a query string.
Double encoding, and how to spot it
When a URL passes through two systems that each escape it, you get double encoding. A space becomes %20, then the percent sign itself gets escaped and you have %2520. The tell is a %25 sitting where you did not put one.
Decoding once gives you a string that still contains percent sequences. That is your confirmation. Decode again and you have the original. Our tool has a Use result as input button precisely for this, because working out how many layers deep you are is otherwise fiddly.
The fix is upstream, not downstream: find which of the two systems should not be encoding. Repeatedly decoding at the far end is a patch that breaks the first time someone types a real percent sign.
Where this bites SEO
Search engines treat two URLs differing by one character as two different pages. A page reachable at both the encoded and the unencoded form is a duplicate, and duplicates split your signals between addresses instead of concentrating them.
Pick one canonical form and use it consistently in internal links, canonical tags and your sitemap. Mixing %20 and + for the same page is how a site ends up with four versions of one URL in the index — and an unescaped ampersand is the most common reason a sitemap fails validation outright, which the sitemap format guide goes into.
If a generated sitemap is quietly listing both forms, that is also crawl budget going nowhere. How to Stop Crawl Waste From Eating Your Rankings covers the parameter side of the same problem.
When to encode by hand at all
In application code, almost never — your language has a correct implementation and using it is better than doing it manually. Manual encoding is for the moments in between.
- Building a test URL to reproduce a bug someone reported.
- Pasting a URL with non-ASCII characters into a config file, a redirect map or a sitemap.
- Reading a logged URL that arrived double-encoded and working out what was actually requested.
- Constructing a
Disallowpattern for robots.txt where the path contains something unusual — the Robots.txt Generator handles the file, but the path is yours to get right.
In all four cases the risk is the same: getting it slightly wrong and not noticing until it affects a user whose input happened to contain the character you forgot.