How to Decode a URL: Turning %XX Escapes Back into Readable Text
A log line full of %3D and %20 is hard to read at a glance. This guide explains how percent-decoding works, the + versus space gotcha, and how to recover the original text instantly and privately.
Copy a URL out of a server log, an analytics export, or a browser address bar and you will often find it stuffed with %3A, %2F, and %20 in place of colons, slashes, and spaces. That is percent-encoding doing its job of keeping the URL safe to transmit - but it makes the value nearly impossible to read at a glance, especially once a query string with several parameters gets involved.
This guide walks through what URL decoding actually reverses, the quirks that catch people out (like a lingering + that never turns into a space), and how to get back to plain text in one step using the URL Decoder - a free tool that decodes entirely in your browser without sending your data anywhere.
What does decoding a URL actually do?
URL decoding is the reverse of percent-encoding. When a character cannot safely appear in a URL - a space, an ampersand, a non-ASCII letter - it gets replaced with a % followed by two hexadecimal digits representing that character's byte value. Decoding scans the string for those %XX sequences and converts each one back to the original character.
The data itself does not change during decoding, only its representation. %20 and a literal space are the same character; one is just written in a form that survives being pasted into a URL, header, or form field without ambiguity. Decoding simply undoes that transformation so you can read the value the way it was originally typed.
Decode a full URL
A query string with an encoded path, name, and space.
Input
https%3A%2F%2Fexample.com%2Fpath%3Fname%3DJohn%20DoeOutput
https://example.com/path?name=John DoeWhy you need to decode URLs in the first place
Encoded values show up constantly in day-to-day development work, and reading them raw wastes time and invites mistakes:
- Log analysis - server and CDN logs typically store request paths and query strings exactly as they arrived, still percent-encoded.
- OAuth and SSO debugging -
redirect_uriandstateparameters are almost always encoded, and a subtle decoding mistake can make a redirect fail silently. - Analytics exports - UTM parameters and search terms captured by tracking tools are frequently encoded, especially when they contain spaces or non-English text.
- Support tickets - a user pastes a broken link, and the fastest way to see what it actually contains is to decode it rather than mentally translating
%3Dto=.
How percent-decoding works under the hood
Decoding walks the string left to right. Any character that is not a % passes through unchanged. When a % is found, the decoder reads the next two characters as a hexadecimal byte - %20 is 0x20, the space character; %3D is 0x3D, an equals sign. In JavaScript, this is what decodeURIComponent() and decodeURI() do internally, the mirror images of encodeURIComponent() and encodeURI().
Non-ASCII characters complicate things slightly because they are encoded as multiple UTF-8 bytes, each escaped separately. The letter é becomes the two-byte sequence %C3%A9. A correct decoder buffers consecutive escaped bytes and reassembles them as UTF-8 before producing the final character, rather than decoding each %XX in isolation - otherwise you get mojibake instead of the accented letter or emoji you expected.
Where does your data go?
Decoding is pure text processing, so it never needs to leave your device. The URL Decoder runs entirely in your browser using the standard JavaScript decoding functions - nothing is uploaded, logged, or stored. That makes it safe to decode redirect URLs, session tokens, or customer-supplied values that you would rather not paste into a server-side tool.
Step-by-step: decode a URL in seconds
- Open the URL Decoder and paste the percent-encoded value or full URL you want to read.
- If the string came from a query string or HTML form submission, enable 'treat + as space' so form-encoded spaces resolve correctly.
- Review the decoded text that appears instantly below the input.
- Copy the result to reuse in a ticket, a test case, or a debugging note.
There is no configuration beyond the plus-sign toggle, and the whole loop happens live as you type or paste - no submit button, no round trip to a server.
Common use cases for URL decoding
- Reading query parameters captured in server, CDN, or analytics logs.
- Inspecting an OAuth
redirect_uriorstateparameter while debugging a login flow. - Turning an encoded search term back into a readable phrase.
- Understanding why a URL behaves differently than expected once its real content is visible.
- Recovering the original value of a form field that was submitted with
application/x-www-form-urlencodedencoding.
Common mistakes when decoding URLs
The lingering plus sign
Percent-decoding by itself does not touch +. That conversion is a separate convention from application/x-www-form-urlencoded data, where a literal + represents a space. If your decoded output still shows + where you expected a space, the input came from a form or query string and you need the 'treat + as space' option turned on - otherwise John+Doe stays John+Doe instead of becoming John Doe.
Double-encoded values
Sometimes a value gets encoded twice - once by a form, again by a proxy or a careless bit of code that re-encodes an already-encoded string. You will recognize it by sequences like %2520, where the original %20 had its own % re-escaped to %25. One decoding pass only removes one layer; run the result through the decoder a second time to fully recover the original text.
Malformed or truncated escapes
A % that is not followed by two valid hex digits, or a UTF-8 byte sequence that is incomplete, will cause a decoding error rather than silently producing garbage. This usually means the value was truncated when it was copied, or that it was never valid percent-encoding to begin with - check the source before assuming the decoder is at fault.
Decoding is not validation
A successfully decoded string does not guarantee the underlying URL is safe or well-formed. Always validate and sanitize decoded values before using them in a redirect, a database query, or rendered HTML.
Best practices for working with encoded URLs
- Decode once per encoding layer - if you are unsure how many times a value was encoded, decode repeatedly until the output stops changing.
- Turn on 'treat + as space' specifically for query strings and form submissions, and leave it off for path segments where a literal
+is meaningful. - When debugging OAuth or SSO issues, decode the full
redirect_uriandstateparameters rather than eyeballing the raw escapes - a single misread%3Dcan hide the real problem. - Pair decoding with URL Encoder when you need to go the other direction, and keep Base64 Decode on hand since encoded tokens are sometimes Base64 wrapped inside a percent-encoded value.
- For sensitive redirect URLs or tokens, use a decoder that runs locally rather than pasting them into a server-side service you do not control.
Related tools
Related guides
Spaces, ampersands, and accented letters break URLs unless they are percent-encoded first. This guide covers how URL encoding works, when to use it, and how to avoid the mistakes that cause broken links.
Base64 encoding turns bytes into safe text, and decoding undoes that step. This guide covers how decoding works, why URL-safe tokens need extra care, and how to recover the original text without uploading it anywhere.
Minified JSON is unreadable and hard to debug. This guide covers how JSON formatting works, when to use it, common mistakes, and how to pretty-print JSON without uploading it anywhere.