About the URL Encoder / Decoder
A URL may only contain a restricted set of ASCII characters, and a handful of those characters are reserved because they carry structural meaning: ? starts the query, & separates parameters, = splits a key from its value, / separates path segments, and # begins the fragment. Percent-encoding is how everything else gets carried safely - each byte becomes a % followed by two hex digits, so a space becomes %20 and é becomes %C3%A9.
The reason a tool like this needs three modes rather than one is that the platform has three different rules, and picking the wrong one is the single most common URL bug there is. Encoding a whole URL with the rule meant for a single value destroys it; encoding a single value with the rule meant for a whole URL lets an ampersand inside that value split it into two parameters.
Everything runs in your browser. URLs frequently carry session identifiers, signed download links, and search terms, and none of what you paste here is uploaded or logged.
How to use this tool
- Choose a mode. Component for one query value, Full URL for an entire address, Form for data going into an application/x-www-form-urlencoded body.
- Paste your text into the input box. The hint under the mode selector tells you exactly what the selected rule does.
- Press Encode or Decode. The result appears in the output box below, and nothing is rewritten in place, so your original stays put.
- If the input contains a query string, read the table at the bottom - it lists every parameter with its value already decoded, which is usually the answer you actually wanted.
- Press Use output as input to chain another operation, which is how you unpick a value that was encoded twice.
Component, full URL, and form: which rule when
Component mode is encodeURIComponent. It escapes the reserved characters as well as the unsafe ones, so &, =, ?, and / all become percent escapes. That is exactly right for a value you are about to drop into a query string, because it guarantees the value cannot be mistaken for structure. Use it when you are building a URL out of pieces.
Full URL mode is encodeURI. It leaves ://, ?, &, and = alone, on the assumption that they are doing their structural job, and escapes only the genuinely unsafe characters such as spaces and non-ASCII text. Use it when you have a complete URL that a human typed and you want to make it legal without breaking it apart.
Form mode is the application/x-www-form-urlencoded serializer, the format an HTML form posts by default. It is component mode with one difference that causes an outsized amount of trouble: a space is written as + rather than %20. Both appear in the wild, sometimes in the same URL, and a decoder that does not know which convention was used will either leave stray plus signs in your text or turn real plus signs into spaces.
Why + and %20 are not interchangeable
In a query string, both %20 and + decode to a space, because form decoders are required to treat + that way. Everywhere else in a URL - in the path, for instance - a + is a literal plus sign with no special meaning at all. So the same three characters mean different things depending on which side of the ? they fall.
The practical consequence: a value like C++ or 1+1 must be encoded as C%2B%2B or 1%2B1 before it goes into a query string. Send it raw and the receiving form decoder reads those pluses as spaces, and a search for C++ silently becomes a search for C followed by two spaces. This tool's Form mode escapes a literal + correctly, which is the behaviour you want whenever the data might contain one.
Double encoding, and how to recognise it
If you see %2520 in a URL, the value was encoded twice. The first pass turned a space into %20, and the second pass escaped that pass's own % as %25, giving %2520. It happens whenever an already-encoded value is passed through an encoder again, typically because two layers of code each assume the other did not do it.
Decoding twice fixes the symptom. Finding which layer encodes is the real repair, and the rule that prevents recurrence is to encode exactly once, at the point where you assemble the URL, and never on a value you received already assembled. Press Decode twice here to confirm you are looking at a double-encoding problem before going to hunt for it in the code.
Frequently asked questions
- Which mode should I use if I am not sure?
- Component, if you are encoding one value such as a search term or a redirect target. Full URL, if you are handing over an entire address and only want the illegal characters cleaned up. Form, if the data is going into a POST body or a query string produced by an HTML form.
- Why did decoding leave %26 untouched?
- You were in Full URL mode. decodeURI is the exact inverse of encodeURI, so it deliberately does not decode escapes for reserved characters - turning %26 into a bare & would change where one parameter ends and the next begins. Switch to Component mode to decode everything.
- Is my URL uploaded anywhere?
- No. Encoding and decoding both happen in your browser and nothing is transmitted or stored. That matters for URLs carrying signed tokens or session identifiers, which routinely appear in the links people need to debug.
- Why does my decoded text contain question marks or boxes?
- The escapes were probably not UTF-8. Percent-encoding carries bytes, not characters, and a value encoded in an older charset such as Latin-1 will produce the wrong characters when decoded as UTF-8. If the sequence is not valid UTF-8 at all, this tool reports an error rather than quietly substituting replacement characters.
- Can I decode a URL that was encoded twice?
- Yes - decode it, press Use output as input, and decode again. The tell-tale sign that you need to is a %25 in the string, which is an encoded percent sign and therefore evidence that an encoder ran over already-encoded text.
