URL Encoder / Decoder

Percent-encoding (also called URL encoding) is a mechanism for representing arbitrary data using only characters that are safe to transmit in a URL. It works by replacing each unsafe byte with a three-character sequence: a percent sign followed by two hexadecimal digits representing that byte's value. A space becomes %20, an ampersand becomes %26, a question mark becomes %3F. The encoding operates on bytes, not characters — so a multi-byte UTF-8 character like an emoji becomes multiple percent-encoded sequences, one per byte.

The reason this exists is historical: URLs were originally defined as ASCII-only, and the characters that carry structural meaning in a URL (?, &, =, /, #, :) can't appear in data without ambiguity. Rather than restricting what data can be sent, percent-encoding lets any byte sequence travel safely inside a URL component, with the understanding that the recipient will decode it before use.

RFC 3986 divides the ASCII character set into unreserved and reserved characters. Unreserved characters — A-Z, a-z, 0-9, hyphen, period, underscore, and tilde — never need encoding in any URL component. Reserved characters have special meaning: / separates path segments, ? starts the query string, & separates query parameters, = separates keys from values, and so on. These characters are allowed in a URL, but their meaning depends on context — a & in a path segment is just a character, while a & in a query string is a parameter delimiter.

This is why you can't encode a whole URL and expect it to work: encoding https://example.com/path?q=1 would produce https%3A%2F%2Fexample.com%2Fpath%3Fq%3D1, which is a valid percent-encoded string but no longer a functional URL — the structural characters that make it a URL have been escaped. The rule is to encode each component individually, then assemble them into a URL structure.

The query string is where percent-encoding matters most in practice. When you submit an HTML form with method="GET", the browser serializes the form fields into a query string, percent-encoding both names and values. A search for "rock & roll" becomes ?q=rock+%26+roll or ?q=rock%20%26%20roll — both are valid, and this ambiguity around spaces and the plus sign is a persistent source of confusion.

The plus-sign-as-space convention comes from the application/x-www-form-urlencoded MIME type, which was designed for HTML forms rather than URLs proper. In a URL path, a plus sign is just a plus sign — it does not mean a space. But in a query string or form body, a plus is conventionally decoded as a space for backward compatibility. This is why URL decoders offer a 'plus as space' toggle: turning it on handles form data correctly, turning it off handles URLs where a literal plus was intended.

The terms URL encoding and URI encoding are often used interchangeably, but the distinction matters at the edges. RFC 3986 defines URIs and specifies percent-encoding for URI components. application/x-www-form-urlencoded is a separate encoding defined by the HTML spec for form submission data — it uses the same percent-encoding mechanism but adds the plus-as-space rule and historically encoded spaces as + rather than %20. JavaScript's encodeURIComponent() implements RFC 3986 encoding (spaces become %20), while the older encodeURI() leaves structural characters unescaped because it's designed to work on complete URIs rather than individual components.

The practical difference shows up in two places: spaces (encodeURIComponent produces %20, form encoding produces +) and certain characters like !, ', (, ), and * which encodeURIComponent leaves unencoded but form encoding escapes. If you're building query parameters for a fetch() request or a URL string, use encodeURIComponent() on each key and value. If you're constructing a form body for a POST request, the plus convention is what the server expects.

The most frequent encoding bug is double-encoding: encoding a value that's already encoded, turning %20 into %2520 (where %25 is the encoding of the literal %). This happens when data passes through multiple layers that each encode independently — a URL builder that encodes values you've already encoded by hand, or a server that decodes once and then decodes again. The fix is to encode exactly once, at the point where the URL is assembled, and never pre-encode values that will be encoded by the tooling.

Unicode introduces its own edge cases. A character like é is two bytes in UTF-8 (0xC3 0xA9), so it encodes to %C3%A9 — not to a single percent sequence. Decoding %C3%A9 as Latin-1 instead of UTF-8 produces the mojibake é, which is why any URL decoder that doesn't specify its encoding will produce garbled text for non-ASCII input. Always decode percent-encoded bytes as UTF-8 unless you have a specific reason to do otherwise.