URL Decoder Online

Q: Why do I see %2B instead of + in decoded output?

The %2B sequence represents a literal plus sign (+) that needs to remain encoded. In query strings, unencoded + is interpreted as space due to application/x-www-form-urlencoded format. If your data contains literal plus signs (like in Base64 strings or math expressions), they must stay encoded as %2B to avoid ambiguity. For example, "a+b=c" in a query parameter should be "a%2Bb%3Dc" to preserve the plus sign. The decoder correctly leaves %2B as-is in the first pass. If you need the literal + character visible, decode a second time, but be aware this may break parameter parsing in some systems.

Q: Should I decode the full URL or just parameters?

Decode parameter values and path segments individually—never decode the entire URL structure. Decoding "https://" produces invalid URLs. The scheme (https), host (example.com), and delimiters (/, ?, &, =) should never be encoded or decoded. Only parameter values and path segments need decoding. For example, decode the query value "error%20rate" to "error rate", but leave the structure "?q=" intact. Indiscriminate full-URL decoding breaks routing and causes 400 Bad Request errors. Use URL parsing libraries to extract components, decode values individually, then reconstruct the URL if needed.

Q: How do I detect double encoding in URLs?

If decoded output still contains many %XX sequences unexpectedly, you likely have double-encoding. For example, decoding "%252F" yields "%2F" instead of "/" because it was encoded twice. Double-encoding happens when an already-encoded URL gets encoded again—common in redirect chains, email templates, or nested API calls. To fix: decode twice until no more %XX sequences appear in values that should be plain text. Alternatively, compare character counts—double-encoded URLs have roughly 3x expansion per character. Always check encoding layers in your pipeline to prevent double-encoding at the source.

Q: Which specification governs percent encoding and decoding?

RFC 3986 defines URI syntax, reserved characters, and percent-encoding rules. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special meaning in URLs and must be percent-encoded when appearing in data values. Unreserved characters (A-Z, a-z, 0-9, - . _ ~) never need encoding. Percent-encoding represents each byte as %HH where HH is hexadecimal. The spec distinguishes between different URL components (scheme, authority, path, query, fragment) with different encoding requirements. Follow RFC 3986 for standards-compliant URL handling, though real-world systems sometimes deviate (like using + for space in query strings per application/x-www-form-urlencoded).

Decode percent-encoded URLs instantly to reveal original text, query parameters, and path components. Transform %20, %2B, and other encoded characters back to readable format for debugging and verification.

Why Use URL Decoder Online

Percent-encoded URLs are unreadable—sequences like %20, %3A, %2F obscure actual content and make debugging impossible. This decoder converts encoded URLs back to human-readable text, revealing query parameters, paths, and special characters hidden by encoding. Essential for debugging API requests, inspecting redirect URLs, verifying query string parameters, and understanding link targets in logs and analytics. The decoder handles standard encoding (%20 for space), plus encoding (+), URL-safe variants, and nested double-encoding that breaks when decoded incorrectly.

Instant decoding: Paste encoded URL and see decoded output immediately
RFC 3986 compliant: Follows URI percent-encoding specification
Handles edge cases: Double-encoding, mixed encoding, malformed sequences
Preserves structure: Maintains URL components (scheme, host, path, query)
Browser-safe: All decoding happens locally—URLs never transmitted

Decode URL Now →

Choose the Right Variant

This page: URL decoding for debugging and verification
Decode URL: Alternative decoding interface
URL Encoder Online: Opposite operation—encode URLs
Encode URL: Encode for safe transmission

Step-by-Step Tutorial

Copy an encoded URL from browser address bar, API logs, or redirect parameter
Example encoded input: https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Derror%2520rate%26category%3Dapi
Paste the encoded URL into the decoder input field
Click "Decode" to convert percent-encoded sequences
Decoded output reveals readable URL: https://example.com/search?q=error%20rate&category=api
Notice the double-encoded space (%2520) became single-encoded (%20)
For fully readable text, decode again: https://example.com/search?q=error rate&category=api
Use decoded URL to understand request parameters or debug issues

Decoding Features

Percent-decoding: Converts %HH sequences to original characters
Plus handling: Decodes + as space in query strings (application/x-www-form-urlencoded)
UTF-8 support: Decodes multi-byte sequences for international characters
Double-encoding detection: Identifies and handles nested encoding layers
Reserved character preservation: Maintains URL structure delimiters (/, ?, &, =)
Error tolerance: Handles malformed sequences gracefully without crashing

Real-World Use Case

A developer investigates why users report broken links in password reset emails. The support ticket includes a screenshot showing a reset URL that doesn't work. The URL in the screenshot looks normal, but copying the actual link from the email source reveals: https://app.example.com/reset?token=aB3%252BcD9%252F%253D. The developer pastes this into the URL decoder and discovers double-encoding: the %2B, %2F, and %3D sequences decode to %2B, %2F, and %3D again—meaning the original token "aB3+cD9/=" was encoded twice. The backend expects "aB3+cD9/=" but receives "aB3%2BcD9%2F%3D" because the email template encoder wasn't accounting for pre-encoded tokens. The developer fixes the email template to stop double-encoding, redeploys, and password resets start working. Total debugging time: 5 minutes instead of hours of guesswork. The decoder revealed the exact encoding mistake causing the failure.

Best Practices

Decode URLs when debugging HTTP 400 errors related to malformed requests
Check for double-encoding if decoded output still contains %XX sequences
Verify query parameter values after decoding match expected input format
Use decoded URLs in documentation for better human readability
Preserve URL structure—decode parameter values individually, not entire URLs
Test decoded URLs in target application to ensure proper interpretation

Performance & Limits

URL length: Decodes URLs up to 500,000 characters (browser limits)
Decode speed: Instant decoding for typical URLs (< 5 KB)
Large URLs: 100 KB encoded URL decodes in ~50ms
Batch decoding: Process multiple URLs sequentially for log analysis
Character encoding: Full UTF-8 support for international characters
Offline mode: Fully functional offline after page loads

Common Mistakes to Avoid

Decoding entire URLs: Decode parameter values only—decoding "https://" breaks structure
Not detecting double-encoding: If output has %XX, you likely need to decode again
Assuming + is always space: In paths, + is literal; in query strings, + decodes to space
Decoding reserved characters: /, ?, &, = should remain encoded in parameter values
Ignoring encoding mismatches: Backend expecting UTF-8, receiving ISO-8859-1 encoded data
Using decoded URLs in HTTP requests: Re-encode parameter values before sending requests

Privacy and Data Handling

All URL decoding happens locally in your browser using JavaScript's native decodeURIComponent() function. Your URLs never leave your device and are never uploaded to any server. The decoder processes URLs entirely in memory without logging or storing content. However, decoded URLs may reveal sensitive data hidden by encoding—API keys, session tokens, email addresses, or personal information in query parameters. For URLs from production systems, use this tool in private browsing mode. Never share decoded URLs containing authentication tokens or sensitive parameters in support tickets, screenshots, or public documentation. Strip sensitive parameters before sharing decoded URLs.

Frequently Asked Questions

Why do I see %2B instead of + in decoded output?

The %2B sequence represents a literal plus sign (+) that needs to remain encoded. In query strings, unencoded + is interpreted as space due to application/x-www-form-urlencoded format. If your data contains literal plus signs (like in Base64 strings or math expressions), they must stay encoded as %2B to avoid ambiguity. For example, "a+b=c" in a query parameter should be "a%2Bb%3Dc" to preserve the plus sign. The decoder correctly leaves %2B as-is in the first pass. If you need the literal + character visible, decode a second time, but be aware this may break parameter parsing in some systems.

Should I decode the full URL or just parameters?

Decode parameter values and path segments individually—never decode the entire URL structure. Decoding "https://" produces invalid URLs. The scheme (https), host (example.com), and delimiters (/, ?, &, =) should never be encoded or decoded. Only parameter values and path segments need decoding. For example, decode the query value "error%20rate" to "error rate", but leave the structure "?q=" intact. Indiscriminate full-URL decoding breaks routing and causes 400 Bad Request errors. Use URL parsing libraries to extract components, decode values individually, then reconstruct the URL if needed.

How do I detect double encoding in URLs?

If decoded output still contains many %XX sequences unexpectedly, you likely have double-encoding. For example, decoding "%252F" yields "%2F" instead of "/" because it was encoded twice. Double-encoding happens when an already-encoded URL gets encoded again—common in redirect chains, email templates, or nested API calls. To fix: decode twice until no more %XX sequences appear in values that should be plain text. Alternatively, compare character counts—double-encoded URLs have roughly 3x expansion per character. Always check encoding layers in your pipeline to prevent double-encoding at the source.

Which specification governs percent encoding and decoding?

RFC 3986 defines URI syntax, reserved characters, and percent-encoding rules. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special meaning in URLs and must be percent-encoded when appearing in data values. Unreserved characters (A-Z, a-z, 0-9, - . _ ~) never need encoding. Percent-encoding represents each byte as %HH where HH is hexadecimal. The spec distinguishes between different URL components (scheme, authority, path, query, fragment) with different encoding requirements. Follow RFC 3986 for standards-compliant URL handling, though real-world systems sometimes deviate (like using + for space in query strings per application/x-www-form-urlencoded).