URL Decoder

The plus sign ambiguity, and why it is an option rather than a default

Two different standards assign a meaning to + in a URL, and they disagree.

RFC 3986, which defines URL syntax, treats + as a literal plus sign. It is a valid character in a path and in a query, and it means what it looks like.

The form-encoding convention application/x-www-form-urlencoded, which is what an HTML form submits, repurposes + as a shorthand for a space. This is a historical artefact of form handling, and it applies only to the body of a form submission and to query strings produced by one.

The problem is that you often cannot tell which convention produced a given string. A query string in a link might have come from a form, or might have been built by hand or by a library that used %20. Deciding wrongly corrupts the value in one direction or the other:

• Decode a literal plus as a space, and a phone number +1-555-0100 becomes 1-555-0100, a base64 fragment loses a character, and a mathematics query reshapes itself.
• Leave a form-encoded plus alone, and salt+and+pepper stays as three words joined by plus signs rather than becoming a phrase.

The honest answer is that this cannot be inferred from the string alone, so the tool does not guess. The option is off by default, which is the conservative choice: leave a plus as a plus unless you have reason to believe the value came from a form.

Double encoding, and how to recognise it

Encoding is not idempotent. Encode an already-encoded value and every percent sign gets escaped again, so %20 becomes %2520 — the % is itself encoded as %25, followed by the original digits.

This happens in practice for understandable reasons. A redirect parameter contains a URL, so that inner URL gets encoded once as a value. If the resulting outer URL is then placed inside another URL, or passed through a system that encodes query parameters generically, it gets encoded a second time. Nothing is broken at any single step; the layers simply stack.

The signature is the string %25, which is an encoded percent sign. Seeing it is a strong signal that at least one more decode is waiting:

• %2520 — decode once to get %20, decode twice to get a space.
• %253A%252F%252F — decode twice to get ://, the mark of a URL embedded in a URL.
• %2526 — decode twice to get &, a parameter separator that was encoded as data and then encoded again.

Ticking Decode repeatedly keeps applying the decode until the output stops changing, which resolves any depth of nesting without you having to count layers. It is safe to leave on for genuinely single-encoded input, because the second pass finds nothing left to decode and returns the same string.

Malformed input, and why strict decoders return nothing

The standard decode function throws on invalid input and returns no output at all. That is unhelpful when you are trying to read a value you received from somewhere else and you have no control over its quality.

Two kinds of malformed escape cause this:

• A lone percent sign. A % not followed by two hexadecimal digits is not a valid escape. This is common in strings where a literal percent is genuinely part of the data — a discount label, a format string, a URL that contains % without encoding it as %25.
• A truncated escape. %2 at the end of the string, or %GG where the digits are not hexadecimal. Both mean something was cut off or mis-typed.

This tool decodes as far as it can and tells you that part of the input was left untouched, so you still see most of the value rather than an empty box. That is deliberately the opposite of the strict behaviour, because the common situation is forensic — you have a malformed string and want to extract as much meaning as possible from it, not fail cleanly.

If the output still contains percent signs after decoding, there are two explanations. Either the input was encoded more than once, in which case turn on Decode repeatedly, or those percent signs are literal characters that were never escapes. The correct encoding for a literal percent is %25, so a well-formed URL containing a percentage sign should decode cleanly.

Reading a URL as parts rather than as a string

When the input is a URL, the tool breaks it into its components, and that breakdown is often more useful than the decoded text on its own.

The pieces are worth knowing by name, because most debugging conversations use them:

• Scheme — https, mailto, data. Determines how the rest is interpreted.
• Host — the domain, and with it the security boundary. A redirect parameter whose host differs from the one you expect is worth noticing.
• Path — the resource within that host.
• Query — everything after the question mark, as key-value pairs.
• Fragment — everything after a hash. This is never sent to the server, which is why single-page applications use it for routing state.

Seeing the parameters split out as decoded pairs is the fastest way to answer questions like which tracking parameters a marketing link actually carries, whether the redirect parameter points somewhere you expect, and what the expiry timestamp in a signed URL actually is.

To go the other direction — turning a value into a safe URL component — the URL Encoder offers query, path and full-URL modes so the encoding matches where the value is going.