Decoding URLs and Reading Query Strings
Paste an encoded URL or query string and this tool converts the percent-escapes back into readable characters. %20 becomes a space, %26 becomes an ampersand, and UTF-8 byte sequences reassemble into the original characters.
Decoding is mostly a debugging activity. Encoded URLs are perfectly readable to machines and almost unreadable to people, so when something goes wrong in a redirect, an analytics report, or a server log, decoding is the first step to understanding what you are actually looking at.
When you need to decode
- Reading a redirect chain where the destination is passed as an encoded parameter.
- Understanding what an analytics report row actually contains when a landing page URL is full of escapes.
- Debugging an OAuth or SSO flow, where callback URLs are routinely nested and encoded.
- Reading server logs, which store the encoded form of every requested URL.
- Checking what a shortened or tracked link expands to before clicking it.
Recognising double-encoding
If decoding once leaves you with visible %20 or %26 sequences still in the output, the string was encoded twice. This shows up as %2520 in the original — the percent sign itself was escaped to %25, so one pass of decoding only unwraps the outer layer.
Double-encoding is a real bug rather than a curiosity. It usually means a value passed through two systems that each encoded it, or that a developer encoded a URL that was already encoded. The receiving server ends up with literal percent-escape text instead of the intended value, and the request fails or behaves oddly.
The fix is to find which layer is encoding redundantly rather than to decode twice and move on. Decoding twice makes the immediate symptom go away while leaving the bug in place.
Nested URLs inside parameters
One of the most common encoded structures is a full URL passed as the value of a parameter — return_to, redirect_uri, next, and similar. The inner URL must be encoded, otherwise its own query string would be parsed as part of the outer URL's parameters.
Decoding these reveals the flow: where a login will send you afterwards, where a tracking redirector actually points, or which page an error handler came from. It is also worth checking for security reasons, since an unvalidated redirect parameter pointing at an external domain is the classic open-redirect vulnerability.
For URLs with several parameters, the URL Parameter Extractor is usually faster than reading a decoded string — it splits and decodes each parameter into its own row.
Decoding and tracking parameters
Decoded campaign URLs are much easier to audit. A tagged URL from an agency or partner is often a wall of escapes; decoded, you can immediately see whether the utm_medium says email or newsletter, and whether the values follow your naming convention.
Once you can read them, the URL Cleaner strips the tracking parameters entirely if you need the clean canonical version — for a sitemap entry, an internal link, or a backlink request.
What the decoder cannot do
It reverses percent-encoding only. Other encodings that look superficially similar are different things: Base64 strings, Punycode domain names beginning xn--, and HTML entities like & all need their own conversion.
It also cannot expand shortened URLs. A bit.ly link is not encoded, it is a redirect — to see where it lands, trace it with the Redirect Chain Checker, which follows every hop server-side.
Malformed input is returned unchanged rather than throwing an error. If a string contains a stray percent sign not followed by two valid hex digits, decoding it is undefined, so the tool leaves the text as-is rather than silently corrupting it.
The reverse operation
To go the other way — turning text into a safe URL value — use the URL Encoder. The pair is useful together when debugging: decode to understand, edit, then re-encode before putting the value back into a URL.
If you are constructing campaign URLs rather than debugging them, the UTM Builder handles the encoding automatically so you never have to think about it.
Frequently asked questions
Why does my decoded URL still contain %20?
It was double-encoded. Look for %2520 in the original — the percent sign itself was escaped, so one decoding pass only removes the outer layer. Rather than decoding twice, find the system that is encoding redundantly.
Can it decode shortened URLs?
No. A shortened link is a redirect, not an encoding — there is nothing to decode. Use the Redirect Chain Checker to follow it server-side and see the final destination.
Is Base64 the same as URL encoding?
No. Base64 encodes binary data into text using a 64-character alphabet; URL encoding escapes unsafe characters with percent sequences. They look different — Base64 rarely contains percent signs and often ends with equals padding.
What happens with malformed input?
The text is returned unchanged. A stray percent sign not followed by two valid hexadecimal digits is not decodable, so the tool leaves the string alone rather than producing corrupted output.
Does decoding change the URL's behaviour?
The decoded form is for reading, not for use. Putting a decoded URL containing spaces or ampersands back into a browser or a link will break it — re-encode before using it anywhere real.