URL Encoder and Decoder

Component or full URL: pick the right one

This is the distinction that causes almost every URL encoding bug. The two modes escape different character sets, and using the wrong one either breaks the URL or fails to protect the value.

Mode	Use for	Leaves unescaped
Component	A single value going into a query string or path segment	Only unreserved characters
Full URL	An entire URL you want to keep functional	Structural characters: : / ? # & =

Encoding a whole URL in component mode turns https:// into https%3A%2F%2F, producing a string that is no longer a URL. Encoding a single value in full-URL mode leaves & and = intact, so a value containing them silently splits into extra query parameters. That second failure is the more dangerous one, because the URL still works, it just carries the wrong data.

The rule of thumb: encode values in component mode, one at a time, as you build the URL. Only use full-URL mode when you have a complete URL containing characters such as spaces that need cleaning up.

Why spaces have two encodings

A space may appear as %20 or as +, and which is correct depends on where it sits. In a path, it is always %20. In a query string, the form-encoding rules used by HTML forms encode it as +, and that convention is widespread enough that most servers accept it there.

Decoders do not universally agree. JavaScript's decodeURIComponent leaves a plus sign as a literal plus, so decoding blue+shoes gives you blue+shoes rather than blue shoes. The + means space option applies the form convention when you know the string came from a query string. Leave it off when a literal plus is meaningful, as in a phone number or an email address using plus-addressing.

Reserved and unreserved characters

RFC 3986 defines the unreserved set as letters, digits, hyphen, period, underscore and tilde. Those never need encoding. Everything else is either reserved, meaning it has structural meaning that encoding would remove, or simply unsafe to transmit raw.

Note that percent itself must be encoded as %25. Forgetting this is what produces double-encoding: a value containing %20 encoded again becomes %2520, and the recipient decodes once to get a literal %20 rather than a space.

Inspecting a URL

The Parse query button breaks a URL into scheme, host, port, path, fragment and query parameters, decoding each parameter value. It also flags repeated parameter names, which are legal but handled inconsistently: some frameworks take the first occurrence, some the last, and some collect all of them into a list. If a URL is behaving unexpectedly, a repeated parameter is worth ruling out early.

Questions

What is the difference between the two modes?

Component mode escapes everything except unreserved characters, which is correct for a single value. Full URL mode leaves structural characters such as colon, slash, question mark and ampersand intact, which is correct for an entire URL. Encoding a whole URL in component mode breaks it.

Should a space be %20 or a plus sign?

In a path, always %20. In a query string, both are widely accepted because HTML form encoding uses the plus sign. Use the plus means space option when decoding a query string, and leave it off when a literal plus matters, such as in an email address.

Why did my URL end up with %2520 in it?

It was encoded twice. The percent character itself encodes to %25, so an existing %20 becomes %2520 on a second pass. Decode once and check before encoding again.

Why does my value split into extra query parameters?

The value contained an ampersand or equals sign and was encoded in full URL mode, which leaves those intact. Encode individual values in component mode so their structural characters are escaped.