URL encode / decode
Encode one value, a whole address, or form data — they are different rules, and using the wrong one is how links quietly break.
Use this for a single query value or path segment. Slashes, ampersands and question marks all get escaped.
| Query key | Decoded value |
|---|
Four sets of rules, not one
“URL encoding” sounds like a single operation and is actually four, and picking the wrong one is how a link ends up broken in a way nobody notices until a customer complains. The difference is which characters are treated as structure and which as data.
Component is the one you want nine times out of ten: you are putting a value inside a URL somebody else built, so every character that could be mistaken for structure — the slash, the ampersand, the question mark, the equals sign — has to be escaped. Whole URI is for an address you already have in one piece: the structural characters are left alone and only spaces, accents and the genuinely illegal characters are escaped. Run a whole URL through the component rules and you get https%3A%2F%2F, which is a string, not a link.
Form data is the odd one out. When a browser submits a form it uses a slightly older convention in which a space becomes a plus sign rather than %20. That is why pasting a form-encoded string into an ordinary decoder leaves plus signs scattered through the result. Strict RFC 3986 exists because JavaScript's own encodeURIComponent deliberately leaves !, ', (, ) and * alone. Most servers do not care. OAuth 1.0 signatures and AWS request signing care a great deal, and a signature mismatch is an opaque error to debug.
Why accented text turns into three escapes
Percent-encoding works on bytes, not letters. Before anything is escaped the text is encoded as UTF-8, and only then is each byte that is not allowed written as a percent sign and two hex digits. So é is two bytes and becomes %C3%A9; an emoji is four bytes and becomes four escapes. This is also the reason a decode can fail on input that looks fine: %C3 on its own is the first half of a character that never arrived, and there is no valid text to produce.
When that happens the tool tells you where the problem is rather than silently returning the input unchanged, which is what several decoders do and which is much harder to debug.
Double encoding, and how to spot it
The most common real bug in this area is a value that has been encoded twice, usually because it passed through two systems that each helpfully escaped it. The tell-tale is %25 in the string — that is an encoded percent sign, which means the percent signs of the first encoding got escaped by the second. Decode it once and you are left with %20 and friends still sitting there.
This page counts what is left after a decode and says so: if escapes remain in the output, it tells you the text was encoded twice, and the send result back to input button lets you peel off the next layer.
The URL breakdown
Paste a complete address and the page also takes it apart: scheme, host, port, path and fragment, plus every query parameter with its value already decoded. This is often the fastest way to see what is actually in a long tracking link, or to find the one parameter whose value was encoded with the wrong rules. Parsing is done with the browser's own URL parser rather than a regular expression, so IPv6 hosts, ports and credentials in the address are all handled the way the browser itself would handle them.
You can also drop a text file onto the input box, which is handy when the string you are debugging is a few thousand characters of signed callback URL and pasting it would be a nuisance.
Common questions
What is the difference between encodeURI and encodeURIComponent?
encodeURI assumes you are handing it a whole address and leaves the characters that give a URL its shape — : / ? # [ ] @ & = + $ , — untouched. encodeURIComponent assumes you are handing it one value that has to survive being placed inside a URL, so it escapes those too. Use the second for query values and path segments, the first for a complete link.
Why does my decoded text still have %20 in it?
Because it was encoded twice. Look for %25 in the original: that is an escaped percent sign, the signature of a double encoding. Decode again — the button that sends the result back to the input is there for exactly this.
When should a space be + and when %20?
Plus is correct inside the query string of an application/x-www-form-urlencoded submission, which is what HTML forms send by default. %20 is correct everywhere else, including in the path. Decoders that convert + back to a space unconditionally will corrupt a path that legitimately contains a plus sign.
Does it handle emoji and non-Latin scripts?
Yes. The text is converted to UTF-8 first, then each byte is escaped, which is what the standard requires. One emoji becomes four escape sequences; Chinese and Arabic characters usually become three each.
It says my input is not valid percent-encoding.
That means one of two things: a % is not followed by two hexadecimal digits, or the escaped bytes do not form valid UTF-8 — usually a character that got cut in half when a string was truncated. The message says which position to look at.
Why escape ! ' ( ) and * as well?
RFC 3986 lists them as reserved sub-delimiters, but encodeURIComponent predates that document and leaves them alone. Ordinary web servers do not mind. Signature schemes that hash the encoded string — OAuth 1.0, AWS Signature V4 — will produce a mismatch, so use the strict mode there.
Is my text sent anywhere?
No. Encoding and decoding use the routines already built into your browser, and the URL breakdown uses your browser's own URL parser. Nothing is transmitted, which matters if the link you are debugging contains a session token.
Can I paste a whole file?
Yes — paste it, or drag a text file onto the input box. There is no length limit beyond your tab's memory.