URL Encoder & Decoder

A URL's structure relies on specific characters — `/` to separate path segments, `?` to introduce the query string, `&` to separate parameters, `#` for a fragment — carrying fixed structural meaning wherever they appear. If a value being placed inside a URL, such as a search term or a user's name, happens to contain one of those same characters literally, there has to be some way to distinguish "this ampersand is part of the actual value" from "this ampersand separates two query parameters." Percent-encoding is that mechanism: any character with structural meaning, when it needs to appear as literal data rather than as structure, gets replaced with a `%` followed by its hexadecimal byte value, so `&` becomes `%26` and unambiguously reads as data rather than as a parameter separator.

The single most common URL-encoding mistake is encoding an entire assembled URL with the wrong function — using `encodeURIComponent`, which escapes every reserved character including `/`, `:`, `&` and `?`, on a complete address rather than on one individual value. The `://` after the protocol becomes `%3A%2F%2F`, every `&` separating query parameters becomes `%26`, and the URL stops being a URL at all — it becomes one long encoded string with no structure a server can parse. The correct approach is the reverse order: encode each individual value first — the search term, the redirect target, whatever the actual data is — and only then insert those already-encoded values into the surrounding URL structure, never re-encoding the assembled whole afterwards.

This is exactly why this tool offers two distinct modes rather than one generic "encode" button: component mode for encoding a single value that is about to become part of a URL, and full-URL mode for the rarer case of encoding an entire address while deliberately preserving its structural characters.

Two different encoding conventions for spaces both remain in active use today, and they are not interchangeable. Percent-encoding, the general-purpose standard, represents a space as `%20` and is valid anywhere in a URL — the path, the query string, everywhere. The `+` convention for a space comes from an older, narrower standard specifically for HTML form submissions using the `application/x-www-form-urlencoded` content type, and it is only valid inside the query string; a literal `+` appearing in a URL path is not interpreted as a space at all, it is just the character plus. This tool always produces `%20`, which is valid in every context, and correctly decodes both forms when reading an encoded URL back.

Percent-encoding rules apply to any URL regardless of what constructs or consumes it — a webhook payload built by a backend service, a deep link opened by a mobile app, an API request assembled by a script. Anywhere a value that might contain spaces, ampersands, or non-ASCII characters gets interpolated into a URL string, the same encode-the-value-before-inserting-it rule applies, which is why this is as much a backend and scripting concern as a browser one.