URL Decoder
Paste any percent-encoded URL to instantly decode it back to readable text. Useful for debugging, log analysis, and reading API responses.
⏱ 7 min read · Complete guide below
URL Decoder
How URL Decoding Works
- 1Paste your percent-encoded URL or query string into the input box.
- 2The decoder scans for every %XX sequence and replaces it with its corresponding character using the ASCII table.
- 3The decoded, human-readable text appears instantly. Click Copy to copy it to your clipboard.
URL Encoding Reference — Common Encoded Characters
The most frequently encountered encoded characters in real-world URLs are: %20 (space), %2B (+), %26 (&), %3D (=), %3F (?), %2F (/), %3A (:), %40 (@), %23 (#), and %25 (% itself). Unicode characters outside the ASCII range are encoded in UTF-8 bytes, each byte percent-encoded individually — for example, the euro sign € encodes as %E2%82%AC.
What Percent-Encoding Is and Why It Exists
Percent-encoding, also called URL encoding, is the mechanism that lets a URL carry characters it could not otherwise contain. A URL is only permitted a small, safe set of characters — letters, digits, and a handful of symbols like hyphen and underscore — because other characters have special structural meanings (a ? starts the query string, an & separates parameters, a / separates path segments) or are simply unsafe to transmit. To include any of those as data, they are replaced with a percent sign followed by their two-digit hexadecimal code: a space becomes %20, an ampersand %26, and so on. Decoding is the exact reverse — this tool scans for every %XX sequence and restores the original character, turning a cryptic encoded string back into readable text.
Reading Encoded URLs from Logs and APIs
The most common reason to decode a URL is that machines store and pass URLs in their encoded form, which is hard for humans to read. Web-server access logs record every request URL with its parameters percent-encoded, so a search query or form submission appears as a wall of % sequences until you decode it. API request URLs frequently embed JSON, nested parameters, or entire callback URLs as encoded values. Marketing and tracking links bury their utm_ parameters in encoded form, and OAuth and single-sign-on flows pass the destination as an encoded redirect_uri. In every one of these cases, decoding reveals what is actually being sent — which is often the first step in debugging why a request, redirect, or tracking link is not behaving as expected.
Handling Unicode and Double Encoding
Two wrinkles are worth understanding. First, characters outside the basic ASCII range — accented letters, emoji, and non-Latin scripts — are encoded by first converting them to their UTF-8 bytes and then percent-encoding each byte, which is why a single euro sign appears as three percent groups (%E2%82%AC). A correct decoder reassembles those bytes back into the original character automatically. Second, you may encounter double-encoded URLs, where a value was encoded, then encoded again — common when a URL is passed as a parameter inside another URL. In that case a %2520 is really an encoded %20, and you simply decode twice to fully unwrap it. Because this tool decodes in your browser, you can run it repeatedly on the output to peel back each layer.
When URL Decoding is Useful
Reading Server Logs
Web server access logs store URLs in their encoded form. Decoding them reveals the actual search queries, form inputs, and API parameters that users submitted.
Debugging API Calls
REST API request URLs often contain encoded JSON or nested query parameters. Decoding the URL reveals the actual payload being sent without needing to re-run the request.
Email Campaign Links
Marketing email links often contain encoded tracking parameters (utm_source, utm_campaign, etc.) that are difficult to read in encoded form. Decode them to see the full tracking details.
Inspecting Redirects
OAuth and SSO flows pass redirect URIs as encoded query parameters. Decoding reveals the actual destination URL when debugging authentication issues.
QA and Testing
When verifying that a web form submits the correct data, decoded URLs make it easy to confirm parameter names and values without parsing raw percent sequences.
Web Scraping
Pagination links, search result URLs, and filter parameters scraped from websites often contain encoded values. Decode them to extract the underlying data reliably.
Frequently Asked Questions
What is URL encoding and why are characters percent-encoded?
URL encoding (also called percent-encoding) replaces unsafe or reserved characters in a URL with a % sign followed by their two-digit hexadecimal ASCII code. For example, a space becomes %20, an ampersand becomes %26, and a forward slash inside a query parameter becomes %2F. This is necessary because URLs can only legally contain a limited set of characters — letters, digits, hyphens, underscores, dots, and tildes. Any other character must be encoded.
What does %20 mean in a URL?
%20 is the percent-encoded representation of a space character (ASCII code 32, which is 20 in hexadecimal). Whenever you see %20 in a URL, it means a space was there in the original text. For example, "Hello%20World" decodes to "Hello World". Similarly, %2B is a plus sign, %3D is an equals sign, and %2F is a forward slash.
What is the difference between %20 and + in a URL?
Both represent a space, but in different contexts. In query strings (the part of a URL after ?) submitted via HTML forms, a + sign is used to represent a space — this is called application/x-www-form-urlencoded encoding. In the path portion of a URL or in modern API query strings, %20 is used instead. When decoding, both %20 and + should be treated as spaces, depending on the context.
When would I need to decode a URL?
Common scenarios include: reading query parameters in server logs where values appear encoded; inspecting API request URLs that contain encoded JSON or nested parameters; reading links in marketing emails that include encoded tracking parameters; debugging web application redirects where the destination URL is encoded; and reading webhook payloads where callback URLs are double-encoded.
Can I decode a full URL or just a specific parameter value?
Both are supported. Paste the entire URL to decode all encoded characters at once, or paste just the value portion of a query parameter to decode only that part. Decoding a full URL including the domain and path is safe — the slash separators and other structural characters that are already valid URL characters will remain unchanged.
Is the decoding done in my browser or on a server?
All decoding runs entirely in your browser using JavaScript's built-in decodeURIComponent() function. Nothing is sent to a server. This means your URLs — which may contain sensitive parameters such as tokens, session IDs, or personal data — never leave your device.
How do I decode a URL that looks like it was encoded twice?
Decode it more than once. Double encoding happens when an already-encoded value is encoded again — common when a URL is passed as a parameter inside another URL. You will see telltale sequences like %2520, which is an encoded %20. Simply run the tool on its own output: each pass peels back one layer of encoding until the text is fully readable. Because decoding runs instantly in your browser, repeating it is quick and safe.
Why do some characters turn into several %XX groups when encoded?
Characters outside the basic ASCII range — such as accented letters, emoji, and non-Latin scripts — are first converted to their UTF-8 byte sequence, and each byte is then percent-encoded separately. That is why a single euro sign appears as %E2%82%AC (three bytes) rather than one group. A proper decoder recognises these multi-byte sequences and reassembles them back into the original character automatically, which this tool does.
Is it safe to decode URLs that contain tokens or personal data?
Yes, because the decoding happens entirely in your browser and nothing is sent to any server. That makes it safe to decode URLs containing sensitive query parameters such as session IDs, access tokens, or personal information. Do keep in mind, though, that decoding only makes the data readable — it provides no security in itself, since anyone can decode a URL. Sensitive values in URLs should always be protected in transit by HTTPS.
Will decoding a full URL break its structure?
No. You can safely paste a complete URL including the scheme, domain, path, and query string. The structural characters that are already valid in a URL — such as the slashes, the question mark, and the ampersands separating parameters — are left unchanged, while the encoded %XX sequences within values are converted back to their original characters. The result is the same URL with its readable form restored.