URL Encoder and Decoder

Percent-encoding in one paragraph

A URL is allowed to contain a small set of characters. Everything else gets written as a percent sign followed by the two hex digits of its byte: a space is %20, a hash is %23. Non-ASCII characters are converted to UTF-8 first and then escaped one byte at a time, so é becomes %C3%A9 — two escapes for one character. A tool that produces %E9 instead is using Latin-1 and will break on anything modern.

The characters that never need escaping

RFC 3986 calls them unreserved: the letters A–Z and a–z, the digits 0–9, and the four marks - . _ ~. They mean the same thing escaped or not, so escaping them is legal but pointless, and it makes two identical URLs look different to a cache.

Then there are the reserved characters — / ? # [ ] @ : $ & ' ( ) * + , ; = — which are the punctuation that gives a URL its structure. Whether they need escaping depends entirely on where they sit. Inside a value, a stray & starts a new parameter and silently truncates your data. In the URL itself, it is doing its job.

Which of the two encoders you want

This is the distinction the mode selector above is making, and it is the same one behind JavaScript's two functions:

• Single value (encodeURIComponent) escapes the structural characters as well. Use it for one parameter value, one path segment, one piece of user input. Run it on a whole address and you get https%3A%2F%2Fexample.com, which is correct behaviour and completely useless as a link.
• Whole URL (encodeURI) leaves the structure intact and only escapes things that can never appear raw, like spaces and accented characters. Use it to repair a URL someone typed with a space in it. Never use it on user input you are about to insert, because it will leave an & alone and let the value break out of its parameter.

The plus sign is genuinely ambiguous

In the application/x-www-form-urlencoded format — what HTML forms send, and therefore what most query strings look like — a space is written as +. In RFC 3986, which governs URLs generally, + is a literal plus sign. Both are correct in their own context, and a query string does not tell you which rule produced it.

The practical consequence: a phone number in a query string is a trap. ?tel=+44123 arrives at many servers as " 44123". If a value can contain a plus, encode it as %2B and stop relying on either convention. The parameter table above decodes + as a space, because that is the more common case, which means it shows the wrong thing for values where the plus was literal.

Double encoding, and why you cannot undo it reliably

Encode a string twice and %20 becomes %2520, because the percent itself gets escaped. The tool warns you when it sees that pattern, and when a decode leaves escapes behind. What it cannot do is tell you whether that was a mistake: a URL containing the literal text 100%25 is a perfectly valid thing to store. Once double-encoded data reaches a database, the ambiguity is permanent.

What this tool does not handle

• Internationalised domain names. A hostname like müller.de is not percent-encoded — it is converted with punycode to xn--mller-kva.de, a completely different algorithm. Percent-escapes in a hostname are invalid, and this tool will happily produce them if you ask.
• Normalisation. It does not lowercase the scheme, collapse ../, sort parameters or resolve a relative URL against a base.
• Validation. The output is escaped correctly; that does not mean it is a working address.
• Encoded slashes in paths. %2F is not the same as /, and a lot of servers and proxies reject or silently normalise it before your code ever sees it. If a path segment must contain a slash, test it against the real stack rather than trusting the escape.

Last updated September 19, 2026