Why URLs need encoding
A URL may only contain a restricted set of characters. Anything outside that set — spaces, accented letters, most punctuation, any non-Latin script — must be percent-encoded, meaning replaced by a percent sign followed by the hexadecimal value of each byte. A space becomes %20, an ampersand becomes %26.
Without this, URLs break in ways that range from annoying to genuinely dangerous. A space truncates a link when it is auto-detected in an email. An unencoded ampersand inside a parameter value splits it into two parameters, silently corrupting the data your server receives.
The two modes and why the distinction matters
This is the part that trips people up, and getting it wrong produces bugs that are hard to trace.
Component mode encodes aggressively, including the characters that give a URL its structure: ampersand, question mark, slash, colon and equals. Use it when encoding a single value that will be placed inside a URL, such as a search term or a redirect target passed as a parameter. If a user searches for "cats & dogs", the ampersand must be encoded or the server will read it as a parameter separator.
Full URI mode preserves structural characters and encodes only what is genuinely illegal. Use it on a complete URL that is already correctly formed and just needs cleaning up. Applying component encoding to a whole URL mangles it — the protocol's colon and every slash get encoded, producing something no browser can follow.
The rule of thumb: encode the parts, not the whole. Build the URL structure yourself and encode each value individually as you insert it.
The plus sign problem
Historically, HTML form submissions encoded spaces as plus signs rather than %20. Both conventions remain in circulation, which means a literal plus sign in a query value is ambiguous. This tool converts plus signs to spaces when decoding, which is correct for form data but occasionally wrong for other sources. If your decoded output has spaces where plus signs should be, that is the cause.
Double encoding
A frequent bug is encoding a string twice, which turns %20 into %2520 because the percent sign itself gets encoded. The symptom is literal percent sequences appearing in your page output. If you see this, something in your chain is encoding a value that was already encoded — a common result of a framework doing it automatically and the developer doing it again by hand.
Security relevance
Proper encoding is a genuine defence. Unencoded values inserted into URLs are a route to open redirect vulnerabilities and to reflected cross-site scripting. Always encode user-supplied values before placing them into a URL.
Runs locally
Everything is processed in your browser, which matters since URLs frequently contain session tokens and API keys.
Frequently Asked Questions
Which mode should I use?
Component for individual values being inserted into a URL. Full URI for a complete, already-structured URL. Using component mode on a whole URL breaks it.
Why does %20 sometimes appear as a plus sign?
Form submissions historically encoded spaces as plus signs. Both conventions are still in use, which makes a literal plus in a query value ambiguous.
What causes %2520 to appear?
Double encoding. A value that was already encoded got encoded again, turning the percent sign of %20 into %25.
Do I need to encode a whole URL?
Rarely. Encode individual values as you insert them into a URL you are constructing, rather than encoding the finished string.
Is encoding a security measure?
It is a necessary part of one. Encoding user-supplied values prevents open redirects and reflected cross-site scripting, though it is not sufficient on its own.