Decode percent-encoded URLs and URI components back to plain text.
Percent-encoded strings appear throughout web development. These are the five contexts where developers most often need to decode them:
Each %XX sequence is one byte expressed in hexadecimal, defined in RFC 3986. ASCII characters map one-to-one; non-ASCII characters use multiple sequences for the UTF-8 byte sequence:
These four issues cover the vast majority of decoding failures. Each shows what goes wrong and the correct approach.
URL decoding (percent-decoding) reverses percent-encoding. Each %XX sequence is replaced with the character whose UTF-8 byte value matches the two hexadecimal digits. For example, %20 becomes a space, %C3%A9 becomes é, and %2F becomes /.
%20 is the RFC 3986 percent-encoding for a space character and is valid everywhere in a URL. The + sign represents a space only in application/x-www-form-urlencoded data (HTML form submissions and query strings). In URL paths, + is a literal plus sign. Use query string mode when decoding form data; use component or full URL mode everywhere else.
Each %XX sequence represents one byte in hexadecimal. For ASCII characters, one sequence maps to one character: %41 = A (hex 41 = decimal 65). For non-ASCII characters, multiple sequences together encode one character: %C3%A9 are the two UTF-8 bytes for é (U+00E9). Paste the sequence here and component mode decodes it instantly.
Two possible causes: (1) the string was double-encoded — your decoded output is itself a percent-encoded string that needs decoding again; (2) the % is a literal percent sign that was correctly encoded as %25. If the output contains %25, decode again to get the actual % character.
The params table view (available in encode mode) parses a query string or full URL and displays each parameter as a row with its key, raw value, and encoded value side by side. This makes it easy to inspect which characters in each value are being encoded and why.
Yes. Percent-encoded non-ASCII characters use UTF-8 byte sequences. %C3%A9 decodes to é, %E6%97%A5%E6%9C%AC%E8%AA%9E decodes to 日本語, and so on. The decoder reads the byte sequence and reconstructs the original Unicode character.
Yes. Decoding runs entirely in your browser using the native decodeURIComponent() JavaScript API. No data is transmitted to any server. You can verify this by opening DevTools → Network — there are no outbound requests while using the tool.