URL Encoder & Decoder

Percent-encoding (URL encoding) replaces characters that are unsafe or reserved in a URL with a % followed by their hex byte value — so a space becomes %20, < becomes %3C, and a literal % becomes %25. It keeps query strings, path segments, and form submissions unambiguous. This tool works both ways: type text to percent-encode it, and paste an encoded value to decode it — and because attackers frequently double-encode to slip past filters, the decode side shows both a single and a double pass.

How you'll use it. Put a value in the encode box to make it URL-safe (component encoding, so &, =, ?, and / are escaped). Paste an encoded string in the decode box to read it in plain text. The single-decode output is what a normal application would see; the double-decode output reveals what a value looks like if it was encoded twice — for example %253Cscript%253E decodes once to %3Cscript%3E and again to <script>.

Why double-encoding matters. A classic filter-bypass works like this: a WAF or input validator decodes the request once, sees a harmless %3Cscript%3E, and lets it through; a downstream component decodes it again and gets live <script>. The same trick defeats naive path-traversal filters (%252e%252e%252f → ..%2f → ../). Seeing both layers side by side makes these payloads obvious.

Common mistake. Confusing component encoding with full-URL encoding. encodeURIComponent escapes the structural characters that separate parameters; encodeURI leaves them intact because it expects a whole URL. Decoding a full URL with component semantics can therefore over- or under-decode structural characters. This tool encodes and decodes as a component, which is what you want for individual parameter values.

Defensive angle. Decode input exactly once, then validate and treat the result as data — never decode in a loop until nothing changes, and never make a security decision on a still-encoded string. Canonicalize before you authorize, and reject input that arrives multiply-encoded when a single layer is all your API legitimately uses. Percent-encoding frequently wraps other layers, so if a decoded value still looks encoded, try the Base64 or hex tools next — and if the payload is script aimed at a browser, the HTML entity encoder shows what safe output should have looked like.