URL Decoder — Percent-Decode URLs Online

When a URL decoder processes a percent-encoded string, it scans for the pattern % followed by exactly two hexadecimal digits. The hex pair is converted to its decimal byte value, and the resulting bytes are interpreted as UTF-8 to reconstruct Unicode characters. For single-byte ASCII characters (code points 0-127), the conversion is one-to-one: %41 decodes to "A" and %20 decodes to a space. For multi-byte Unicode characters, multiple consecutive percent-encoded sequences decode together as a UTF-8 sequence. For example, %E3%81%82 represents three bytes that together form the UTF-8 encoding of a Japanese hiragana character. A decoder that only handles single bytes without UTF-8 awareness will produce garbled output for non-ASCII content. Additionally, the + character used in HTML form submissions is treated as a space by most URL decoders, separate from its literal %2B representation.

Double-encoding is one of the most frequent URL-related bugs: a value is encoded once (giving %20), and then that encoded string is encoded again (giving %2520, because % itself becomes %25). When decoded once, %2520 becomes %20, still encoded, rather than the intended space. This happens when code encodes a value that was already encoded, or when a middleware layer adds a second round of encoding. Another common pitfall is partial encoding, where only some characters in a value are encoded. For instance, a URL may have spaces encoded as %20 but leave & unencoded, causing query string parsers to incorrectly split the value at the ampersand. When debugging, always decode the full raw URL from the network layer rather than the version processed by a framework, so you see the actual bytes that were transmitted.

Web server access logs typically record the raw request URL exactly as received from the client, including all percent-encoded characters. A search query with spaces may appear in logs as /search?q=my%20search%20term rather than the readable form. Decoding such log entries is essential for understanding what users actually searched for, diagnosing 404 errors caused by misencoded links, and auditing incoming requests for suspicious patterns. When you paste a log entry containing encoded characters into a URL decoder, you can instantly read the human-meaningful values rather than manually looking up each hex code. Monitoring tools and log aggregators sometimes decode URLs automatically, but raw log access from SSH or downloaded log files will show the original encoded form, making a decoder indispensable for day-to-day web development debugging.

REST APIs often include encoded values in URLs, especially when resource identifiers can contain slashes, spaces, or Unicode text. When an API call fails or returns unexpected results, decoding the full request URL is one of the first debugging steps. Browser developer tools display decoded URLs in the address bar but show the raw encoded form in the Network panel request headers, which is the more accurate view for debugging. OAuth and single sign-on flows frequently pass tokens, return URLs, and state parameters as encoded query string values. When a redirect fails, comparing the encoded value in the request against the expected value after decoding often reveals mismatches caused by inconsistent encoding practices or string truncation at an intermediate proxy or load balancer.

Not every string that looks percent-encoded is actually valid. A % character not followed by exactly two valid hexadecimal digits is an encoding error. Passing such a string to a decoding function will throw an exception in most languages: JavaScript's decodeURIComponent throws a URIError, Python's urllib.parse.unquote raises an error for malformed sequences, and PHP's urldecode silently passes through invalid sequences. Before decoding untrusted input in production code, validate that the input contains only legal percent-encoded sequences, or wrap the decode call in a try/catch block and handle errors gracefully. This tool displays an error badge for invalid input so you can identify malformed sequences and correct them before using the data in your application logic.