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. The question that actually matters is which of the three encoders to use, because they escape different sets of characters and picking the wrong one breaks the link.
Three encoders, three jobs
Query value — encodeURIComponent. Use this for one parameter value. It escapes every reserved character, including : / ? # & = +. Paste a whole URL in here and it comes back fully escaped, which looks alarming but is correct when that URL is itself a parameter, such as a redirect target.
Whole URL — encodeURI. Use this for a complete address you want to stay clickable. Structural characters are left in place; only genuinely unsafe ones such as spaces and non-ASCII text are escaped.
Form data. Identical to the first mode, then every %20 becomes +. This is the application/x-www-form-urlencoded convention that HTML forms and classic query strings use.
Each mode has a matching decode. If the input is not valid percent-encoding — a stray % with no two hex digits behind it, for instance — the page reports the problem inline and leaves your text alone. 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 repaired. The second and third are that link packaged as a value you could hand to ?redirect=. Neither is more correct than the other; they answer different questions.
The plus sign is the classic bug
+ means a space in a query string, and it also appears 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, including form mode: the %20-to-+ swap runs after encoding, so it only ever touches spaces that the encoder produced. a+b comes back as a%2Bb in every mode. The bug is not in the encoder — it is in pasting an address into a URL without encoding it at all.
Two gaps worth knowing about
The JavaScript encoders are not a complete implementation of RFC 3986, and this page uses them directly rather than patching over the difference. !, ', (, ) and * are left unescaped by encodeURIComponent, though the specification lists them as reserved sub-delimiters. Most servers cope. A few — OAuth signature checks are the usual culprit — do not, and you will have to escape those five by hand.
The decoders are also not symmetrical with each other. decodeURI deliberately refuses to decode escaped structural characters, so a%26b comes back unchanged rather than as a&b. Decoding with the same mode you encoded with avoids this entirely; mixing modes is where round trips go wrong.
Encoding is not protection
This is a formatting step and nothing more. A percent-encoded token looks scrambled and is one function call from being read by anyone who has it. Encoding an API key does not conceal it.
Keep secrets out of URLs altogether. Query strings are written to browser history, to server access logs, to proxy logs, and to the Referer header sent to whatever third-party script the destination page loads. That exposure is unaffected by how the value is spelled.
Nearby developer tools
- Base64 Encoder — the other encoding people mistake for encryption.
- JWT Decoder — read the claims inside a token you are passing around.
- Case Converter — kebab-case for the slug you are 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.