URL Encode / Decode

URLs are limited to a small ASCII set, and inside that set several characters already have jobs. A question mark starts the query string, an ampersand separates parameters, an equals sign splits a key from its value, a hash marks the fragment, a slash separates path segments, and a plus sign means a space in form-encoded data. Any of these appearing inside a value rather than as structure must be percent-encoded or the URL will be parsed wrongly.

The classic failure is a redirect parameter. Writing ?next=/search?q=shoes gives the parser two question marks, and everything after the second is silently swallowed. Encoding the value to %2Fsearch%3Fq%3Dshoes preserves it exactly. Spaces are the other constant: they become %20 in a path and either %20 or a plus in a query string, which is why a space is safest encoded rather than left alone.

This is the mistake that produces links which look right and do not work. If you encode an entire URL, the slashes in https:// and the separators between parameters get encoded too, and the result is one meaningless string. If you encode nothing, embedded values break the structure.

The rule is to encode each value, then assemble. In JavaScript, encodeURIComponent() is the function for a single value: it encodes slashes, question marks, ampersands, and equals signs. encodeURI() is for a complete URL and deliberately leaves those structural characters alone. Reaching for encodeURI() on a query parameter is the usual cause of a broken redirect, and reaching for encodeURIComponent() on a whole URL is the usual cause of a link that 404s on a path like https%3A%2F%2F.

Double encoding is the related trap. Encoding an already-encoded string turns every percent sign into %25, so %20 becomes %2520 and the value arrives with visible escape codes in it. If you see %25 in a URL, something ran the encoder twice.

Anything outside ASCII is first converted to UTF-8 bytes and then percent-encoded byte by byte, which is why non-Latin text expands so much. The Hindi word नमस्ते becomes %E0%A4%A8%E0%A4%AE%E0%A4%B8%E0%A5%8D%E0%A4%A4%E0%A5%87, three encoded bytes per character. An emoji takes four. This matters because some servers and proxies still cap URL length around 2,000 characters, and a query string of encoded non-Latin text reaches that faster than it looks.

Domain names work differently. The host part of a URL cannot be percent-encoded at all; internationalised domains use Punycode instead, so a domain in Devanagari or Chinese is transmitted as an xn-- prefixed ASCII string. Browsers display the readable form and send the Punycode. Path and query components use percent-encoding as normal, which is why one URL can carry both schemes at once.