Decode URL

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

The %2B sequence represents a literal plus sign (+) that must remain encoded to avoid ambiguity. In query strings, an unencoded + is interpreted as a space character due to application/x-www-form-urlencoded format conventions. If your data contains literal plus signs (common in Base64 strings, mathematical expressions, or programming operators like "C++"), they must stay encoded as %2B to distinguish them from spaces. For example, a search query for "C++ tutorial" should be encoded as "C%2B%2B%20tutorial" where %2B preserves the plus signs and %20 represents the space. The decoder correctly leaves %2B intact during the first pass. Decode a second time if you need to see the literal + character, but be aware this may break parameter parsing in systems expecting %2B notation.

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 output that breaks routing and causes navigation errors. The URL scheme (http/https), host (example.com), port, and structural delimiters (/, ?, &, =) should never be percent-encoded or decoded. Only the data within parameter values and path segments needs decoding. For example, in "site.com/search?q=hello%20world", decode "hello%20world" to "hello world" but leave "site.com/search?q=" unchanged. Indiscriminate full-URL decoding destroys URL structure and causes HTTP 400 Bad Request errors. Use URL parsing libraries to extract components, decode values individually, then reconstruct the URL if needed for display or documentation purposes.

Q: How do I detect double encoding in URLs?

If decoded output still contains many %XX sequences unexpectedly, you're dealing with double-encoding. Double-encoding occurs when an already-encoded URL gets encoded again—common in redirect chains, email templates, nested API calls, or misconfigured proxies. For example, decoding "%252F" yields "%2F" instead of "/" because it was encoded twice (/ → %2F → %252F). To fix: decode multiple times until no more %XX sequences appear in values that should be plain text. Alternatively, compare character expansion—double-encoded URLs show roughly 3x character count growth per special character. Always trace your encoding pipeline to identify where double-encoding occurs and prevent it at the source rather than patching with extra decode steps.

Q: Which specification governs percent encoding and decoding?

RFC 3986 defines URI syntax, reserved characters, and percent-encoding rules that govern URL encoding and decoding. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special structural meaning in URLs and must be percent-encoded when appearing in data values. Unreserved characters (A-Z, a-z, 0-9, - . _ ~) never require encoding. Percent-encoding represents each byte as %HH where HH is two-digit hexadecimal (0-9, A-F). The specification distinguishes between different URL components (scheme, authority, path, query, fragment) with component-specific encoding requirements. Follow RFC 3986 for standards-compliant URL handling, though real-world systems sometimes deviate—for example, using + for space in query strings per the application/x-www-form-urlencoded format (HTML forms), which predates RFC 3986 but remains widely supported for backward compatibility.

Decode percent-encoded URLs instantly to reveal readable query parameters, paths, and special characters hidden by encoding. Essential for debugging API requests, inspecting redirects, and verifying URL integrity.

Why Use Decode URL

Encoded URLs obscure critical debugging information—%20, %3A, %2F sequences hide actual parameter values and make troubleshooting impossible. This decoder transforms percent-encoded URLs back to human-readable text, revealing query strings, path components, and special characters masked during transmission. Essential for debugging broken API calls, inspecting redirect chains, verifying query parameters in logs, understanding analytics tracking URLs, and diagnosing encoding-related failures. Unlike manual decoding that misses edge cases, this tool handles standard encoding, plus-to-space conversion, UTF-8 multi-byte sequences, and nested double-encoding that breaks when decoded incorrectly. Supports RFC 3986 percent-encoding rules and application/x-www-form-urlencoded format variations.

Instant decoding: Convert encoded URLs to readable text in milliseconds
RFC 3986 compliant: Follows URI specification for percent-decoding
Edge case handling: Detects double-encoding, mixed formats, malformed sequences
UTF-8 support: Decodes international characters and emoji correctly
Browser-safe: All decoding happens locally—URLs never transmitted

Decode URL Now →

Choose the Right Variant

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

Step-by-Step Tutorial

Copy encoded URL from browser logs, redirect parameters, or API responses
Example encoded input: https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Derror%2520rate%26filter%3Dcritical
Paste the URL into the decoder input field
Click "Decode" to convert percent-encoded sequences
First decode reveals: https://example.com/search?q=error%20rate&filter=critical
Notice double-encoded space (%2520) became single-encoded (%20)
Decode again for fully readable text: https://example.com/search?q=error rate&filter=critical
Use decoded output to understand query parameters or identify encoding issues
Copy decoded URL for documentation or bug reports

Decoding Features

Percent-decoding: Converts %HH sequences back to original characters
Plus handling: Decodes + as space in query strings (form-encoded data)
UTF-8 decoding: Multi-byte sequence support for international characters
Double-encoding detection: Identifies and warns about nested encoding layers
Structure preservation: Maintains URL delimiters (/, ?, &, =) correctly
Error tolerance: Handles malformed sequences gracefully without failing

Real-World Use Case

A backend engineer investigates customer reports of broken OAuth redirect flows. Users complete authentication successfully but land on error pages instead of being redirected back to the application. The engineer examines server logs and finds redirect URLs like: callback_url=https%253A%252F%252Fapp.example.com%252Fdashboard%253Ftoken%253DxYz123. Pasting this into the URL decoder reveals double-encoding: the first decode produces https%3A%2F%2Fapp.example.com%2Fdashboard%3Ftoken%3DxYz123 (still encoded), and the second decode finally shows https://app.example.com/dashboard?token=xYz123. The OAuth library was encoding callback URLs that were already percent-encoded by the frontend, creating invalid redirect targets. The engineer adds a configuration flag to prevent double-encoding, redeploys, and OAuth redirects start working correctly. Debugging time: 8 minutes instead of hours of trial-and-error. The decoder immediately revealed the exact encoding layer causing the failure, preventing weeks of frustrated customer support tickets.

Best Practices

Decode URLs when investigating HTTP 400 Bad Request errors with malformed parameters
Check for double-encoding if decoded output still contains %XX sequences
Decode only parameter values and path segments—never entire URL structures
Verify decoded query parameters match expected input format and data types
Use decoded URLs in documentation for improved readability
Test decoded URLs in target application to confirm proper interpretation
Strip sensitive tokens before sharing decoded URLs in support tickets

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 processing: Process multiple URLs sequentially for log analysis
Character encoding: Full UTF-8 support including emoji and international scripts
Offline capability: Fully functional offline after initial page load

Common Mistakes to Avoid

Decoding entire URLs: Decoding "https://" breaks URL structure—decode values only
Missing double-encoding: If output has %XX, decode again until readable
Wrong space interpretation: + means space in query strings but literal + in paths
Decoding reserved characters: Don't decode structural delimiters (?, &, =)
Ignoring encoding mismatches: Backend expecting UTF-8 but receiving ISO-8859-1
Using decoded URLs in requests: Re-encode parameter values before HTTP transmission
Not checking context: Different URL components have different encoding rules

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 expose sensitive information hidden by encoding—API keys, session tokens, email addresses, user IDs, or personal data in query parameters. For URLs from production systems or customer reports, use this tool in private browsing mode to avoid browser history exposure. Never share decoded URLs containing authentication tokens, signed parameters, or sensitive user data in screenshots, support tickets, public documentation, or team chat channels. Always strip sensitive parameters before sharing decoded output for troubleshooting purposes.

Frequently Asked Questions

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

The %2B sequence represents a literal plus sign (+) that must remain encoded to avoid ambiguity. In query strings, an unencoded + is interpreted as a space character due to application/x-www-form-urlencoded format conventions. If your data contains literal plus signs (common in Base64 strings, mathematical expressions, or programming operators like "C++"), they must stay encoded as %2B to distinguish them from spaces. For example, a search query for "C++ tutorial" should be encoded as "C%2B%2B%20tutorial" where %2B preserves the plus signs and %20 represents the space. The decoder correctly leaves %2B intact during the first pass. Decode a second time if you need to see the literal + character, but be aware this may break parameter parsing in systems expecting %2B notation.

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 output that breaks routing and causes navigation errors. The URL scheme (http/https), host (example.com), port, and structural delimiters (/, ?, &, =) should never be percent-encoded or decoded. Only the data within parameter values and path segments needs decoding. For example, in "site.com/search?q=hello%20world", decode "hello%20world" to "hello world" but leave "site.com/search?q=" unchanged. Indiscriminate full-URL decoding destroys URL structure and causes HTTP 400 Bad Request errors. Use URL parsing libraries to extract components, decode values individually, then reconstruct the URL if needed for display or documentation purposes.

How do I detect double encoding in URLs?

If decoded output still contains many %XX sequences unexpectedly, you're dealing with double-encoding. Double-encoding occurs when an already-encoded URL gets encoded again—common in redirect chains, email templates, nested API calls, or misconfigured proxies. For example, decoding "%252F" yields "%2F" instead of "/" because it was encoded twice (/ → %2F → %252F). To fix: decode multiple times until no more %XX sequences appear in values that should be plain text. Alternatively, compare character expansion—double-encoded URLs show roughly 3x character count growth per special character. Always trace your encoding pipeline to identify where double-encoding occurs and prevent it at the source rather than patching with extra decode steps.

Which specification governs percent encoding and decoding?

RFC 3986 defines URI syntax, reserved characters, and percent-encoding rules that govern URL encoding and decoding. Reserved characters (: / ? # [ ] @ ! $ & ' ( ) * + , ; =) have special structural meaning in URLs and must be percent-encoded when appearing in data values. Unreserved characters (A-Z, a-z, 0-9, - . _ ~) never require encoding. Percent-encoding represents each byte as %HH where HH is two-digit hexadecimal (0-9, A-F). The specification distinguishes between different URL components (scheme, authority, path, query, fragment) with component-specific encoding requirements. Follow RFC 3986 for standards-compliant URL handling, though real-world systems sometimes deviate—for example, using + for space in query strings per the application/x-www-form-urlencoded format (HTML forms), which predates RFC 3986 but remains widely supported for backward compatibility.