At a glance
| Input | A URL or any text |
|---|---|
| Output | Percent-encoded text, or the decoded original |
| Two modes | Whole URL, or a single query value |
| Where it runs | Entirely in your browser — no file is uploaded to a server |
| Price | Free, with no account and no sign-up |
| Offline | Works with no connection after the first visit |
Two different jobs
Encoding a whole URL and encoding one value inside it are not the same operation, and picking the wrong one is the usual bug.
Component encoding escapes everything that has meaning in a URL, including /, ?, & and =. That is what you want for a single parameter value — an address, a search phrase, a redirect target. Full URL encoding leaves that punctuation intact and escapes only spaces and characters that are never legal, so the URL still works as a URL.
Encode a search term with the full-URL rule and an ampersand inside it silently splits your query into two parameters.
The plus sign
In a query string a space may be written as +, a leftover from HTML form encoding. Elsewhere in a URL, + is a literal plus. So decoding a path with form rules turns C++ into C , and decoding a query without them leaves visible plus signs where the spaces should be.
Percent-encoding a space as %20 is unambiguous everywhere, which is why it is the safer output.
Encoding twice
Running an already-encoded string through again turns every % into %25, and the result looks plausible while being wrong. If you see %2520 in a link, that is a space encoded twice — the fix is upstream, not another decode.
Frequently asked questions
When do I need component encoding rather than full-URL?
Whenever you are putting a value into a URL — a search term, a redirect target, an email address. It escapes & and = so your value cannot break out and become extra parameters.
Why is my space showing as + instead of %20?
Query strings inherited that from HTML form encoding. Both decode to a space inside a query, but only %20 is safe elsewhere in a URL.
What does %2520 mean?
A space that was encoded twice: %20 became %2520 when the % was itself escaped. Something in the chain is encoding an already-encoded string.
Does it handle non-English characters?
Yes — they are encoded as UTF-8 bytes, which is what the standard requires and what every browser expects.
Something wrong with this tool, or an idea for it? Tell us