URL Encoder / Decoder

About URL encoding

URL encoding — properly called percent-encoding — replaces characters that have a special meaning in a URL, or that cannot appear in one at all, with a % followed by the byte's hex value. A space becomes %20, an & becomes %26. Non-ASCII characters are encoded as their UTF-8 bytes, which is why é becomes two escapes, %C3%A9.

Which encoding should I pick?

• Component — for a single value going into a query string or path segment. It escapes / ? : @ & = + $ #, which is what you want when the value must not be mistaken for URL structure. This is the one you need most of the time.
• Full URL — for tidying an entire URL. It leaves the structural characters alone so the URL still works, and only escapes things like spaces.
• Form data — for an application/x-www-form-urlencoded request body, where spaces are + rather than %20.

The classic bug: encoding a whole URL as a component

If you run a complete URL through Component encoding, its :// and ? get escaped and the result is no longer a working URL — it is a URL-shaped string safe to embed as a value, which is only what you want when passing a redirect target as a query parameter. If your links are arriving broken with %3A%2F%2F in them, this is why: use Full URL instead.

Why does decoding fail?

A % must be followed by exactly two hex digits, so a truncated string or a stray literal percent sign breaks decoding — a literal one has to be written %25. The other common failure is double-encoding: text encoded twice and then decoded once leaves escapes that no longer form valid UTF-8. This tool points at the exact character that caused the problem.