URL Encode and Decode
Make text safe for a URL, or turn a messy encoded link back into something readable.
Free forever, no sign-up and no limits, and this tool installs on its own so you can keep it on your home screen.
Percent-encode text so it survives being put in a URL, or decode it back to readable form; the tool detects the direction on its own. Paste a full address and a breakdown shows scheme, host, path and every query parameter decoded on its own row, each with its own copy button. Free, instant, and your text stays with you.
How to use it
- Paste text or a URLAuto picks encode or decode from what you paste and says so. The direction buttons override it, and a full address also gets the breakdown view.
- Say what you are encodingA single value (a query parameter or path segment) or a whole URL. This choice is what most encoders get wrong.
- Copy the resultCopy the whole output, or a single decoded parameter straight from its row in the breakdown.
Why URLs need encoding at all
The URL standard permits a small set of characters: letters, digits, and a handful of symbols. Everything else has to be escaped. Some characters are excluded because they are unsafe in transit, spaces get mangled, quotation marks get eaten by shells. Others are excluded because they already mean something: a question mark begins the query string, an ampersand separates parameters, a hash introduces the fragment.
Percent-encoding solves both problems the same way. Take the character's UTF-8 bytes, write each as two hexadecimal digits, and prefix each with a percent sign. The result contains only safe characters, and any reader knows to reverse it.
The distinction that actually matters
Nearly every online URL encoder gives you one button and quietly picks one behaviour. That is where the bugs come from, because the right answer depends entirely on what you are encoding.
Suppose a user searches for tom & jerry. If you encode only the value, you get tom%20%26%20jerry, and the whole phrase arrives as one parameter. If you encode it as though it were a whole URL, the ampersand survives untouched, and the server reads it as the start of a second parameter. The search silently becomestom, and nobody notices until someone reports that results are wrong.
The reverse mistake is just as common. Encode a complete address with the single-value option and every slash and colon becomes an escape sequence, producing a string that is no longer a URL at all.
Where you will meet it
Query strings and search parameters. OAuth redirect URIs, which must be encoded when passed as a parameter to an authorisation endpoint. API requests carrying filters or dates. Analytics campaign tags. Anywhere a value that might contain punctuation has to travel inside an address.
It also shows up in reverse when you are debugging: a log line full of %2F and%3A is far easier to read once decoded, which is often the reason people reach for a tool like this in the first place.
Questions people ask
What is URL encoding?
A URL may only contain a limited set of ASCII characters. Anything else (a space, an accented letter, an emoji, a slash inside a value) has to be represented as a percent sign followed by the hexadecimal bytes of its UTF-8 encoding. A space becomes %20, an ampersand becomes %26, and é becomes %C3%A9.
What is the difference between the two options?
Encoding a single value escapes the delimiters too, so & = ? / and # become %26 %3D %3F %2F and %23. That is essential when the value itself contains one of them, otherwise it would look like the start of a new parameter. Encoding a whole URL leaves those delimiters alone, because escaping them would destroy the address structure. In JavaScript terms these are encodeURIComponent and encodeURI. As a rule: putting user text into one parameter wants the single value option; a complete address that merely contains spaces or accents wants the whole URL option.
What does the URL breakdown show?
Paste a complete address and every part appears decoded on its own row: scheme, host, path and each query parameter, with a copy button per row. It is the fastest way to fish one campaign tag or redirect target out of a long tracking link without decoding the whole thing by eye.
Why does it say decoded 2 times?
Text sometimes gets percent-encoded twice: a space becomes %20, then the percent sign itself becomes %25, leaving %2520. The tool keeps decoding until the text stops changing and reports how many passes that took, so double-encoded input comes out fully readable instead of half done.
Why does a space sometimes become + instead of %20?
Plus is used specifically in application/x-www-form-urlencoded data, the format HTML forms post in. In a URL path or a modern query string, %20 is correct. This tool always produces %20, which is valid everywhere; if you are decoding old form data, convert plus signs to spaces first.
Why does decoding fail with an error?
Because the input is not valid percent-encoding. Usually there is a bare % that is not followed by two hexadecimal digits, a literal percent sign must itself be written as %25. The tool reports this rather than returning mangled text.
Does it handle non-English characters?
Yes. Text is encoded as UTF-8 first, which is what the URL standard requires, so Sinhala, Arabic, Chinese and emoji all round-trip exactly.
Which characters are safe to leave unencoded?
The unreserved set, and only that: A to Z, a to z, 0 to 9, and the four characters hyphen, full stop, underscore and tilde. Everything else can change the meaning of the address depending on where it lands, which is why encoding a value is the right default even when it looks harmless.