URL Encoder / Decoder
Percent-encode or decode text in three modes: a single query value, a whole URL, or form data where a space becomes a plus.
URL Encoder / Decoder workspace
Nothing to work with yet
Use for one parameter value. Reserved characters (: / ? # [ ] @ & = + $ ,) are all encoded, so a URL pasted in here comes back fully escaped — that is correct when the URL is itself a parameter, such as a redirect target.
Text Statistics
Everything on this page is computed in your browser. Nothing is uploaded, and nothing is saved between visits — closing the tab is enough to clear it.
Using URL Encoder / Decoder
Paste the URL or the single query value into the editor.
Choose an encoding style: query value, whole URL, or form data with spaces written as plus signs.
Read the note under the selector, which says exactly what that mode escapes.
Press Encode or Decode, then copy the result or press Undo to restore the original text.
Three encoders cover the three jobs percent-encoding is used for: escaping one parameter value, escaping a whole address while keeping it clickable, and producing form-encoded data where a space is written as a plus. Each has a matching decoder, and malformed input is reported inline instead of throwing a dialog.
URL Encoder and Decoder
Percent-encoding turns characters that mean something structural in a URL into a % followed by their bytes in hexadecimal, so they survive as data. What you really need to decide is which of the three encoders to use. They escape different sets of characters, and if you pick the wrong one the link breaks.
Three encoders, three jobs
Query value (encodeURIComponent). Use this for one parameter value. It escapes every reserved character, including : / ? # & = +. If you paste a whole URL in here it comes back fully escaped. That looks alarming, but it's correct when the URL is itself a parameter, such as a redirect target.
Whole URL (encodeURI). Use this for a complete address you want to keep clickable. Structural characters stay where they are, and only genuinely unsafe ones such as spaces and non-ASCII text get escaped.
Form data. This works like the first mode, then every %20 becomes +. That's the application/x-www-form-urlencoded convention used by HTML forms and classic query strings.
Each mode has a matching decode. If the input isn't valid percent-encoding (say, a stray % without two hex digits after it), the page reports the problem inline and leaves your text alone. There's no dialog to dismiss.
The same string through each mode
Take https://example.com/search?q=blue widget&page=2.
encodeURI https://example.com/search?q=blue%20widget&page=2
encodeURIComponent https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dblue%20widget%26page%3D2
form https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dblue+widget%26page%3D2The first is a working link with the space fixed. The second and third are that link packaged as a value you could hand to ?redirect=. They're all correct; each one answers a different question.
The plus sign is the classic bug
+ means a space in a query string, but it also turns up inside real data, most visibly in tagged email addresses like ada+news@example.com. Send that unescaped and the receiving system reads a space. The address becomes ada news@example.com, and the confirmation email never arrives.
All three modes escape a literal + to %2B, form mode included. The %20-to-+ swap runs after encoding, so it only ever touches spaces the encoder produced, and a+b comes back as a%2Bb in every mode. When this bug shows up, it's because someone pasted an address into a URL without encoding it at all.
Two gaps to know about
The JavaScript encoders aren't a complete implementation of RFC 3986, and this page uses them as they are, without patching over the difference. encodeURIComponent leaves !, ', (, ) and * unescaped, even though the specification lists them as reserved sub-delimiters. Most servers cope. A few don't (OAuth signature checks are the usual culprit), and for those you'll have to escape the five characters by hand.
The decoders don't mirror each other either. decodeURI deliberately refuses to decode escaped structural characters, so a%26b comes back unchanged instead of as a&b. If you decode with the same mode you encoded with, you'll never hit this. Round trips go wrong when you mix modes.
Encoding is not protection
This is a formatting step and nothing more. A percent-encoded token looks scrambled, but anyone who has it can read it with one function call. Encoding an API key doesn't hide it.
Keep secrets out of URLs altogether. Query strings get written to browser history, server access logs and proxy logs, and they're sent in the Referer header to whatever third-party script the destination page loads. How the value is spelled makes no difference to any of that.
Nearby developer tools
- Base64 Encoder: the other encoding people mistake for encryption.
- JWT Decoder: read the claims inside a token you're passing around.
- Case Converter: kebab-case for the slug you're about to build.
Frequently asked
Which mode should I use for a redirect parameter?
Query value mode. `encodeURIComponent` escapes the colons and slashes inside the target address, which is exactly what is needed when one URL is being carried inside another.
Why does my email address break when it goes through a query string?
A plus sign means a space there, so `ada+news@example.com` arrives as `ada news@example.com`. All three modes escape a literal plus to `%2B`; the failure comes from not encoding the value at all.
Does percent-encoding protect a value?
No. It is a formatting rule that reverses with a single function call. Keep tokens and passwords out of addresses entirely, since query strings reach browser history, server logs and referrer headers.
What happens if the text I paste is not valid percent-encoding?
The page reports the problem inline and leaves your input untouched. A stray `%` with fewer than two hexadecimal digits behind it is the usual cause.