Interpreting percent escapes
Use this tool on one encoded component you copied from a URL. It reconstructs the bytes denoted by percent triplets and then decodes those bytes as UTF-8 text. For example, %20 becomes a space and %26 becomes an ampersand inside the value, not a query separator. This helps when you need to read a parameter from a log or determine what a path segment says. An incomplete percent triplet or an invalid UTF-8 byte sequence is reported rather than quietly replaced.
Do not assume a plus sign becomes a space here. That substitution belongs to form-style query encoding and is not performed by a plain component decoder. Likewise, decoding a complete URL at once may turn escaped separators into active structural characters, changing how a later parser interprets it. Extract the component first, decode it once, and retain the original address when debugging. If a value is encoded twice, the first pass may reveal another percent triplet; only repeat the operation when the data format explicitly calls for two layers.
Percent encoding a URL component
A URL is made of structural separators and values. The slash separates path segments, the question mark begins a query, and the ampersand separates query parameters. When one value contains a space, an ampersand or a non-ASCII character, percent encoding prevents that value from being mistaken for URL structure. The text is first represented as UTF-8 bytes; bytes requiring escaping appear as a percent sign followed by two hexadecimal digits. A space commonly becomes %20, while an accented character usually takes several encoded bytes.
This tool works on one component, like a query value or path segment, rather than on an entire assembled URL. If you encode the whole address, meaningful separators can be escaped too. For web form bodies there is also an application/x-www-form-urlencoded convention in which spaces often become plus signs. That convention differs from the component operation here. Decode only with the matching rules, keep the original URL structure, and let a URL-building API combine individually encoded values whenever you can.
Check the encoded source before decoding
Begin with a value that is actually written in the expected representation. Paste one encoded component or byte sequence, then compare the readable output with the surrounding record that supplied it. The decoder runs in this browser and does not upload the string to a conversion service. If the input is damaged or uses another format, it may fail or remain partly unchanged, depending on the operation. Preserve the original encoded value so that you can identify whether a surprising character came from the source or from your interpretation.
Treat the decoded text as new, potentially untrusted input. A readable sentence can still contain markup, a URL, a command-like string or private information that needs separate handling. Do not insert it into an executable context just because decoding succeeded. If the output seems wrong, verify the declared character encoding and ask whether an earlier system encoded the value more than once. Repeating a decode without understanding the layers can turn a literal separator into structural punctuation or create a result that was never intended by the sender.