Security & devFree
Free URL encode and decode tool. Convert text with encodeURIComponent, encodeURI, or form-style + spaces. Runs locally in your browser.
Last updated 14 October 2026
All three modes do percent-encoding. What separates them is which characters they consider structural and therefore leave alone. Measured here on the eleven reserved characters ;,/?:@&=+$#:
%3B%2C%2F%3F%3A%40%26%3D%2B%24%23.That is the whole difference, and it decides which mode you want:
https://a.com/p?x=1&y=2 in component mode becomes https%3A%2F%2Fa.com%2Fp%3Fx%3D1%26y%3D2, which is correct for a value and useless as a link.If you encode a value with encodeURI, any & or = inside it survives and silently becomes part of the query string, splitting your parameter into two. That is the failure this page exists to prevent, and it does not produce an error, just wrong data at the other end.
encodeURIComponent leaves -, ., _ and ~ alone, which is uncontroversial: RFC 3986 calls them unreserved. It also leaves !, ', (, ) and * alone, which surprises people. Measured: !'()*-._~ comes back as !'()*-._~, all nine characters untouched.
Those five are legal in a URI, so nothing here is wrong. But they are sub-delimiters rather than unreserved characters, and some server-side parsers, shell scripts and older systems treat a bare apostrophe or parenthesis as a problem. If you are handing a value to something strict, escape those five yourself afterwards. This tool will not do it for you and will not warn you.
Form style is encodeURIComponent with %20 rewritten to +. That is the convention HTML forms use, defined in the URL standard as application/x-www-form-urlencoded, and it is not interchangeable with ordinary percent-encoding.
The asymmetry on decode is the part worth knowing, and we measured both halves:
a+b decoded in form style gives a b. The plus became a space.a%2Bb decoded in form style gives a+b. The escaped plus survived as a plus.So a plus sign only survives a round trip if it was escaped on the way in. If you paste something that was not form-encoded into form-style decode, every genuine plus in it becomes a space, and nothing tells you. Phone numbers and arithmetic are where this bites.
Measured, and worth stating because it looks like the tool failed: %2F decoded in encodeURI mode comes back as %2F, unchanged. That is correct behaviour. decodeURI deliberately refuses to decode the escapes for reserved characters, because decoding %2F to a slash would change the structure of the URL it sits in.
If you actually want the slash, decode in encodeURIComponent mode, which decodes everything. Use that for a value; use encodeURI mode when you want to read a URL without breaking it.
Percent-encoding works on bytes, not characters, and the bytes come from UTF-8. Measured: café 🎉 in component mode becomes caf%C3%A9%20%F0%9F%8E%89. The é is two bytes, the space is one, and the emoji is four.
So the length counter under the output is counting characters of encoded text, not characters of your input, and a short string of emoji can become a very long URL. If you are up against a length limit somewhere, that is the number that matters, and it is the one shown.
%253A and decoding once gives you %3A back. One pass per press; press again if you need another level.%ZZ and a bare % give the same message, “Error: invalid encoding”, with no position.Nothing is uploaded. All three modes are built-in browser functions running on your device, and what you paste never leaves it. That matters here more than on most tools, because the text people encode is often a URL with a token or a session id in it.
encodeURIComponent. developer.mozilla.orgencodeURI. developer.mozilla.orgapplication/x-www-form-urlencoded. url.spec.whatwg.orgEvery behaviour and every encoded string on this page was measured against this tool as it is published, in a browser, on 14 October 2026. Where the page says what the tool does not do, that is a statement about this tool, not about URL encoding in general.
If you are encoding one value to drop into a URL, a search term, a filename, an email address, use encodeURIComponent. If you have a complete URL and want to make it safe without breaking it, use encodeURI. The difference is the eleven reserved characters ;,/?:@&=+$#: component mode escapes all of them, URI mode escapes none.
You used component mode on a complete URL, which escaped the colons and slashes as well. Measured: https://a.com/p?x=1&y=2 becomes https%3A%2F%2Fa.com%2Fp%3Fx%3D1%26y%3D2. That is correct for a value you are about to put inside another URL, and useless as a link. Switch to encodeURI mode.
Because they are legal in a URI. RFC 3986 classes !, ', (, ) and * as sub-delimiters, so the browser’s encoder leaves them alone, along with -, ., _ and ~. Some strict parsers and shell scripts still object, so escape them yourself if the receiving end is fussy.
You decoded in form style, which treats a plus as an encoded space before doing anything else. Measured: a+b gives a b, while a%2Bb gives a+b. If the text you pasted did not come from an HTML form, use encodeURIComponent mode instead, which leaves the plus alone.
Because decodeURI refuses to decode the escapes for reserved characters, since turning %2F into a slash would change the structure of the URL. That is deliberate and correct. Switch to encodeURIComponent mode if you want everything decoded.
Percent-encoding escapes bytes, and the bytes come from UTF-8, where an emoji is four bytes and each byte becomes three characters such as %F0. Measured: café 🎉 becomes caf%C3%A9%20%F0%9F%8E%89. The counter under the output is the length of the encoded text, which is the number that matters if you are near a length limit.
A percent sign in your input is not followed by two valid hex digits, so the text cannot be decoded. Both %ZZ and a bare % produce that same message, and it does not tell you where the problem is. Check for a stray percent sign, or for text that was never encoded in the first place.
No. The encoding and decoding are built-in browser functions running on your device, and nothing leaves the page. That is worth knowing here, because the URLs people need to decode often have an access token or a session id in them.