URL Decode & Encode

URLs are only allowed to contain a limited set of characters, so anything outside that set has to be smuggled through using percent-encoding. Each awkward byte is written as a percent sign followed by two hexadecimal digits: a space becomes %20, a slash becomes %2F, and an ampersand becomes %26. This is why a link you copy from a browser can look like a wall of percent signs. Decoding turns that noise back into the human-readable value; encoding does the reverse so your text survives the trip through an address bar, a form submission, or an API call.

Reserved versus unreserved characters

The URL specification splits characters into two camps. Unreserved characters - the letters A to Z, the digits 0 to 9, and the four symbols -, _, . and ~ - are always safe and never need encoding. Reserved characters such as /, ?, #, &, = and : carry structural meaning: they separate the path from the query, one parameter from the next, or a key from its value. When one of those characters needs to appear as literal data rather than as a delimiter, it must be percent-encoded so the parser does not mistake it for punctuation.

encodeURIComponent versus encodeURI

In JavaScript there are two encoders and picking the wrong one causes real bugs. encodeURI is meant for a whole URL and deliberately leaves reserved structural characters like / and ? untouched. encodeURIComponent is meant for a single piece of data - one query value, one path segment - and encodes those reserved characters too, because inside a value they are just text. If you build a link with encodeURI when you should have used encodeURIComponent, an & or = inside your value will split the query and silently corrupt the request.

Why decoding and encoding matter in security testing

Percent-encoding sits right on the boundary between what a user controls and what a server trusts, which makes it a constant companion in web testing. Payloads for injection attacks are frequently URL-encoded so they slip past naive filters that only look for the raw characters. Open-redirect and single-sign-on flows hide their destination inside an encoded redirect or return parameter, so decoding it tells you exactly where a login is about to send the victim. Double-encoding is the classic bypass: a filter decodes once and inspects the result, but the value is encoded twice, so %2520 survives the first pass as %20 and only becomes a real space deeper in the stack. Always study these techniques in labs and systems you are authorised to test.

A quick worked example

Suppose a page loads with ?next=%2Flogin%3Fmsg%3D%3Cscript%3E. Decoding the value once gives /login?msg=<script>, which instantly reveals both the redirect target and an attempt to inject a script tag through the message parameter. Now consider %2520: decode it a single time and you get %20, decode that again and you finally reach a space. Recognising when a value has been wrapped in one extra layer of encoding is often the difference between a filter that holds and one that is trivially bypassed, which is why keeping a decoder within reach is a habit worth building.