URL Encoder & Decoder

What URL encoding is

A URL is only allowed to contain a limited set of characters, and several of those have jobs:? starts the query, & separates parameters, = splits a name from its value, # begins the fragment. Anything else — a space, an accent, an ampersand that's part of a company name — has to be written as % followed by two hex digits of its UTF-8 bytes. A space becomes %20, é becomes%C3%A9.

The three rules, and why picking wrongly breaks things

"URL encoding" isn't one rule, and choosing the wrong one is the most common way to break a link. What changes between them is how the structural characters are treated.

• A single value — for one parameter or path segment. A / or& inside a value is data, so it gets escaped. This is what you want when putting a URL inside another URL, which is why a redirect looks like?next=https%3A%2F%2F….
• A whole URL — leaves :, /, ?,&, = and # alone so the address still works, and escapes only what would break it. Use it to tidy a URL someone typed with spaces in.
• Form data — what a browser sends when a form is submitted. Almost identical to the first, except a space becomes + rather than %20, and!, ', (, ) and ~ are escaped too. This matches URLSearchParams exactly.

Escape a whole URL with the value rule and you get an unusablehttps%3A%2F%2F…. Escape a value with the URL rule and any & in it silently splits your parameter in two. Both happen constantly.

The plus sign problem

In form data a + means a space. Everywhere else it means a plus. Nothing in the text says which you have, so decoding has to guess — and guessing wrong quietly corrupts things, most painfully with base64 values, where + is one of the 64 characters and turning it into a space destroys the data.

This looks at the company the + keeps: name-and-value pairs joined by& mean form data, so + is a space. A bare string with padding at the end looks like base64, so + stays a plus. Whatever it decides is stated under the result, and the switch is there to overrule it.

Encoded twice

When something already encoded is encoded again, every % becomes%25: %20 turns into %2520. It's a common bug in redirect chains and analytics links, and it shows up as a link that decodes to something still full of escapes. This spots it, says so, and offers to decode the next layer.

Reading a long link

Paste any URL — in either direction — and it's pulled apart underneath: scheme, host, port, path, fragment, and every query parameter with its value decoded. A bare query string works too, since that's often all you have from a log line. Parameters whose value is itself a URL are marked, because that's usually the redirect target you were looking for.

Is it private?

Yes. It all happens in JavaScript inside this page — the URLs you paste are never uploaded, never logged, and never sent anywhere, because there's no server involved. Given how often these links carry session tokens and personal identifiers, that matters more here than for most tools. You can disconnect from the internet after the page loads and it keeps working.

Frequently asked questions

Why did my & disappear?

Because it was escaped with the whole-URL rule, which treats & as structure and leaves it alone — so whatever followed became a new parameter. Use the single value rule for anything going inside a parameter.

What's the difference between this and Base64?

Percent-encoding keeps readable characters readable and escapes only what it must, which makes it right for URLs. Base64 rewrites everything into 64 safe characters and is a third larger, which makes it right for binary data. Neither is encryption.

Does it handle non-English text?

Yes. Characters are converted to UTF-8 bytes first and each byte escaped, which is what every modern server expects — so café becomes caf%C3%A9 and comes back identical.

Why won't my text decode?

Almost always a % that isn't the start of an escape — a literal percent sign in prose, which should be written %25. The error says which one and where.