URL encoder and decoder

Why URLs need encoding

A URL may contain only a limited set of ASCII characters, and several of those have a job to do. ? starts the query string, & separates parameters, = splits a name from its value, # starts the fragment and / separates path segments. If a search term or file name contains one of these characters, the browser or server reads it as structure rather than data.

Percent-encoding solves this by writing a problematic character as % followed by two hexadecimal digits. A space becomes %20, & becomes %26, / becomes %2F. Characters outside ASCII are first converted to UTF-8 bytes and each byte is encoded separately, so é becomes %C3%A9 and a single emoji turns into four %XX groups.

Situations where you need it:

• Building a link with a search query, redirect URL or email address as a parameter.
• Putting a URL inside another URL, for example a returnTo or redirect_uri value in a login flow.
• Debugging webhooks and analytics links that arrive as unreadable %-soup.
• Reading server logs, where requested paths are logged in encoded form.

Component mode versus full URL mode

The checkbox Encode a full URL (keep :/?&=) chooses between two different rules, and picking the wrong one is the most common mistake.

Default: encode a component

With the box unticked, everything except letters, digits and - _ . ! ~ * ' ( ) is encoded. This is the right choice for a single value that will go after = in a query string or into one path segment. The text rock & roll/live becomes rock%20%26%20roll%2Flive, which can safely sit in ?q= without breaking the parameter list.

Full URL

With the box ticked, the characters that give a URL its structure are kept: : / ? # & = + , ; @ $ and the ones listed above. Spaces, non-ASCII letters and a few others are still encoded. Use this when you have a complete address that is almost valid, for example https://example.com/files/annual report.pdf, and you only need to fix the space.

Full URL mode cannot tell a structural & from one that belongs inside a value. In https://shop.example/?q=salt & pepper the & stays as it is, and the server sees a broken parameter. In that case, encode the value alone in component mode and paste it into the URL.

Spaces, plus signs and double encoding

There are two conventions for spaces. Path and general URL encoding uses %20; HTML form submissions (application/x-www-form-urlencoded) use +. This encoder always produces %20, which every server understands in both places.

The decoder converts + to a space before decoding, because that is what form-encoded query strings mean. The side effect: a literal plus that was never encoded, such as C++ in a path, decodes as spaces. If the original text contained a real plus sign, it should have been sent as %2B, and that form decodes correctly.

Double encoding is the other classic trap. The % sign itself is encoded as %25, so running an already encoded string through the encoder again turns %20 into %2520. If you see %25 followed by two hex digits in a link that does not work, decode it once and check the result.

When decoding fails

"Not a valid encoded string" appears when a % is not followed by two hex digits, or when the bytes do not form valid UTF-8. Typical causes:

• A truncated link, cut in the middle of a %C3%A9 sequence.
• A literal percent sign, as in 50% off, that was never encoded.
• Text encoded long ago in a legacy single-byte code page such as Windows-1251 or Latin-1, where é is %E9 instead of %C3%A9.

For the first two, fix the broken part by hand. For legacy code pages there is no reliable automatic fix, since the same byte means different letters in different code pages.

Related encodings

Percent-encoding is not the same as Base64, which turns arbitrary bytes into a compact string, nor as HTML entities such as &, which are for text inside HTML. For readable addresses made from titles, a slug generator produces cleaner results than encoding: My Trip to Kraków becomes my-trip-to-krakow instead of My%20Trip%20to%20Krak%C3%B3w.

Encoding and decoding run in your browser, so tokens or private parameters inside the URL are not sent anywhere.