How to decode a URL
- Paste the encoded text or URL into the box above.
- Leave plus-as-space on unless the text came from a path segment.
- Turn on repeat decoding if you can see %25 sequences in the input.
- Read the decoded result below.
- Copy it, or download it as a text file.
What this decoder handles
- Standard percent-encoding, including multi-byte UTF-8 sequences.
- Plus signs converted to spaces, matching form-encoded data.
- Repeat decoding for strings encoded twice or more.
- A report of how many passes were needed.
- Clear errors when a % is not followed by two hex digits.
- Live updating with no upload.
Reading an encoded URL
Encoded URLs are hostile to read. A tracking link, a redirect chain or a logged request arrives as a wall of percent signs, and the interesting part, where it actually points, what the parameters say, is buried in the escapes.
Decoding turns it back into text. %20 becomes a space, %2F becomes a slash, %C3%A9 becomes é. What was unreadable becomes obvious, which is usually all you needed.
The double-encoding problem
If a URL contains %2520, it has been encoded twice. The first pass turned a space into %20; the second pass encoded that percent sign into %25, leaving %2520.
This happens constantly in redirect chains, where a URL is encoded to be a parameter and then the whole thing is encoded again by another layer. Decoding once leaves you with %20 still visible. The repeat option keeps decoding until the string stops changing, and reports how many passes it took, which tells you how many layers of encoding were applied, and therefore roughly where in your pipeline the extra one is coming from.
Plus signs are ambiguous
- In
application/x-www-form-urlencodeddata, which is what HTML forms send, a plus means a space. - In a path segment, a plus is a literal plus character.
Nothing in the string tells you which context it came from, so the option is yours. Plus-as-space is on by default because query strings are what people decode most often. Turn it off when decoding a path, or when the value genuinely contains a plus. A phone number in international format, for example, where turning +44 into " 44" is clearly wrong.
When decoding fails
A percent sign must be followed by exactly two hexadecimal digits. If it is not, the string is malformed and cannot be decoded, usually because it was truncated when copied, or because a literal percent sign was never encoded in the first place.
Malformed UTF-8 sequences fail too. %C3 on its own is the first byte of a two-byte character with the second byte missing, which is a sign the string was cut short.
Reading the parameters properly
Once a URL is decoded, breaking it into components is often the more useful next step. The URL parser separates protocol, host, path, query and fragment, and lists every parameter with its decoded value already in place, which saves decoding by hand at all.
To encode in the other direction, the URL encoder handles both component and whole-URL modes. Everything runs in your browser, so URLs containing session tokens are never transmitted.
What decoding reveals in a tracking link
Marketing and referral links are where percent-encoding piles up most. A link from an email campaign typically wraps the real destination inside a click-tracking service, which wraps it again inside an analytics redirect, each layer encoding the one below it.
Decoding repeatedly unwraps that chain and shows the final destination. That is genuinely useful for two reasons: it tells you where a link actually goes before you follow it, and it exposes the parameters being attached to your visit. If you are auditing a campaign, or simply checking a link you were not expecting, this is the fastest way to see what is really there.