URL Encoder and Decoder

What URL encoding is

A URL has a grammar. ? starts the query string, & separates parameters, = splits a name from its value, / divides path segments and # begins the fragment. Those characters are reserved: they mean something structural. The moment a piece of your data contains one of them, the URL stops meaning what you intended.

URL encoding — properly called percent-encoding — resolves this. Each problematic character is converted to its UTF-8 bytes, and each byte is written as a % followed by two hexadecimal digits. A space becomes %20, & becomes %26, = becomes %3D, and é becomes %C3%A9 because it is two bytes in UTF-8. The receiving side reverses the process and recovers the original value exactly.

Component encoding vs full-URL encoding

This distinction causes more bugs than anything else in this area. When you encode a component — one parameter value, one path segment — you want every reserved character escaped, because the value must arrive as one opaque unit. A search term of shoes & boots has to become shoes%20%26%20boots, or the & will be read as the start of a new parameter.

When you encode a whole URL, the opposite is true: the reserved characters are doing their job and must be left alone, or https://x/y?a=b would collapse into an unusable string. Full-URL encoding therefore escapes only characters that are never legal, such as spaces and control characters. Use the right button for the situation — component encoding on a full URL will mangle it, and full-URL encoding on a parameter value will leave dangerous characters intact.

Characters you will meet most often

The # row is worth dwelling on, because the failure is invisible. A fragment is processed entirely by the client and is never transmitted, so an unencoded # in a parameter value means the server receives a silently truncated request — no error, just missing data.

Common pitfalls

Double encoding

Encoding an already-encoded string escapes the percent signs themselves: %20 becomes %2520, and the far end receives the literal characters %20 rather than a space. This usually happens when two layers both try to be helpful — a client library encodes, then a gateway encodes again. Encode exactly once, at the point the value enters the URL. If output here contains %25 followed by hex digits, you are looking at a double-encoded string; decode it twice to confirm.

Plus signs and form encoding

HTML forms use application/x-www-form-urlencoded, which encodes a space as + rather than %20. Decoders built for that format convert every + back to a space — so a value such as C++ or a phone number like +44 20 7946 0000 arrives corrupted unless the plus was escaped as %2B. The form-specific buttons above apply that convention; the standard ones do not. Which rule applies is decided by the Content-Type of the request — see the HTTP headers guide for how that header steers body parsing.

Encoding is not sanitisation

Percent-encoding preserves data faithfully — including hostile data. It is a transport concern, not a security control. After decoding, input still needs validation, SQL still needs parameterised queries, and anything rendered into a page still needs HTML escaping.

Reserved characters that are legal but unwise

Some characters are technically permitted unencoded in certain positions but cause trouble in practice: ; and , are treated as sub-delimiters by some frameworks, and : is ambiguous in a path. Encoding them in values costs nothing and avoids surprises.

Non-ASCII and internationalised domains

Percent-encoding operates on UTF-8 bytes, so a single accented character becomes two or three escapes and an emoji becomes four. Hostnames are the exception: they use Punycode (xn-- prefixes) rather than percent-encoding, so you cannot percent-encode your way to a valid internationalised domain name.

Frequently asked questions

Related tools and reference