Skip to content
ToolShelf

URL encoder / decoder

Percent-encode text for a query string or a path, decode it back, and see the difference between encoding one component and encoding a whole URL.

Which way?

Plain text

Whatever you paste stays in this tab. The work is done by JavaScript in your browser. None of it is uploaded, logged or saved, and the tool keeps working with the network off.

Which rules?

Encoding rules

Picking the wrong one is quiet: the output looks plausible either way and only breaks once a value happens to contain an ampersand, a slash or a plus.

Encoded

The result appears here as you type.

Three jobs, one name

“URL encoding” covers three different sets of rules, and choosing the wrong one produces output that looks right and breaks later, when a value happens to contain a character that matters.

  • A single value. One parameter, one path segment, one cookie value. Escapes / ? & = # as well, because inside a value those are data, not structure. This is encodeURIComponent.
  • A whole URL. An address that is already assembled. Leaves the structural characters alone and escapes only what cannot appear literally, such as spaces. This is encodeURI.
  • A form field. What a browser posts and what most HTTP libraries build for a form body. Almost the same as a single value, except a space becomes +.

The plus sign, which costs people hours

In form encoding a space is written + and a real plus is written %2B. Everywhere else, + is just a plus. Decode a value with the wrong rules and a phone number like +44 7700 900000 arrives as 44 7700 900000, the leading plus silently gone.

It is worth knowing which end produced the value. A query string built by a browser form will use +; one built by hand or by most APIs will use %20. Both decoders here are exact about it rather than guessing.

Double encoding

If a decoded result still has %20 visible in it, the value was encoded twice, a percent sign became %25, so a%20b became a%2520b. Decode it again. This happens whenever a value passes through two layers that each helpfully encode it, and the symptom is unmistakable once you know it.

It runs in your browser

Both directions use the platform’s own functions, on this page, with no request made. That matters here because query strings are where session tokens, signed parameters, email addresses and redirect targets live, the sort of thing that should not be pasted into somebody else’s server to be tidied up.

Paste a complete URL and it is also taken apart: scheme, host, path and every query parameter with its value already decoded. A parameter carrying an encoded URL of its own becomes readable, which is usually the thing you wanted in the first place.

Questions

What is the difference between encoding a value and encoding a whole URL?
Which characters are treated as structure. Encoding a single value escapes / ? & = # as well, because inside one parameter those are data. Encoding a whole URL leaves them alone, because there they are what makes it a URL. Run a complete address through the value rules and you get https%3A%2F%2F…, correct as a parameter, useless as a link.
Why is a space sometimes %20 and sometimes +?
Both are correct, in different places. %20 is the general percent-encoding of a space and works anywhere. The + comes from form encoding, the format a browser posts a form in, where a space is written as + and a literal plus is written %2B. Use + only for form bodies and query strings built the same way.
Why did the plus sign in my data turn into a space?
Because it was decoded with form rules when it was not form-encoded. A phone number like +44 7700 900000 comes back as " 44 7700 900000". The plus quietly becomes a space. Switch the rules to a single value, where + is just a plus. This is the most common percent-encoding bug there is.
Is anything I paste here sent to a server?
No. Encoding and decoding both run in your browser using the platform's own encodeURIComponent, encodeURI and their inverses. Nothing is requested, logged or stored, which matters because URLs often carry session tokens, signed parameters and personal data in their query strings.
What does "URI malformed" mean?
That a percent sign was not followed by two hex digits, usually a truncated string, or a literal % that should have been written %25. This tool says which character is at fault instead, because finding a stray percent sign in a long query string by eye is miserable.
Why can it decode the escapes but still refuse?
Because well-formed escapes can still spell bytes that are not valid UTF-8, %C3%28, for instance. That normally means the value was encoded in a different character set, or that something has been encoded twice with different rules. The escapes are fine; the bytes underneath them are not text.
What is double encoding?
Encoding something that was already encoded, so % becomes %25 and a%20b becomes a%2520b. It happens when a value passes through two layers that each helpfully encode it. If a decode leaves you with visible %20s still in the text, decode it a second time. That is the signature.
Why does it show me the query parameters?
Because that is usually the real question. Paste a full URL and its scheme, host, path and parameters are listed with every value already decoded, so a parameter containing an encoded redirect URL becomes readable instead of being a wall of %3A%2F%2F.

More tools