URL Encoder/Decoder
Encode or decode URLs and query parameter values, with a choice between full-URI and query-component encoding.
About the URL Encoder/Decoder
Pick "Query Component" mode when you're encoding a single value headed into a query string, it escapes / : ? & = and the other reserved characters. Switch to "Full URI" mode for an entire URL that needs its structural characters left alone, escaping only spaces and other unsafe characters. Both modes run right in your browser.
The exact character sets each mode leaves untouched
Query Component mode (encodeURIComponent) leaves only letters, digits, and the characters - _ . ! ~ * ' ( ) unescaped, everything else, including / : ? & = ; , + # $ @, gets percent-encoded. Full URI mode (encodeURI) additionally leaves the URI-reserved delimiter characters (; , / ? : @ & = + $ #) alone, since these are what a valid URI actually uses to separate its own structural pieces, the path from the query string, one parameter from another, and so on. The distinction maps directly onto RFC 3986's concept of "reserved" versus "unreserved" characters, reserved characters carry structural meaning in a URI and shouldn't be blindly escaped when you're encoding a whole URL, but need escaping when they appear inside a single value that isn't supposed to be structural.
The real bug this distinction exists to prevent
Imagine a search query value that itself contains an ampersand, like "salt & pepper." If you encode that value with Full URI mode (or don't encode it at all) and drop it straight into a query string as ?q=salt & pepper, the raw & gets misread by any URL parser as the start of a brand new parameter, silently splitting your intended single value into two separate, broken parameters. Encoding that same value with Query Component mode instead turns the ampersand into %26, which safely travels through as literal data rather than being misinterpreted as query-string structure. This exact mistake, encoding a value meant for one query parameter with the wrong mode, is one of the most common real-world URL bugs, and it's precisely why the two modes exist as separate options rather than one universal "URL encode" button.
What makes a percent-escape sequence "malformed"
Decoding fails with an error under two specific, well-defined conditions: a % character not followed by exactly two valid hexadecimal digits, or a percent-encoded byte sequence that doesn't reassemble into valid UTF-8 when decoded. The second case happens if encoded bytes get truncated or corrupted, say only part of a multi-byte encoded character survived a copy-paste, leaving the remaining bytes unable to form a complete, valid character. This tool catches both failure modes and surfaces one clear message rather than letting the raw, more cryptic native error propagate.
Why some URLs use %20 for spaces and others use a plus sign
Both encoding modes here convert a literal space into %20, the correct representation per the URI specification. That's worth knowing because it's genuinely not the only convention you'll encounter: HTML form submissions using the standard application/x-www-form-urlencoded content type specifically encode spaces as + instead, an older, separate convention from plain URI encoding. If you're decoding a query string that came from an HTML form submission and it doesn't look right, that's often why, a raw + needs to be converted to a space before percent-decoding, which is a different processing step than what this tool's decode mode performs on its own. If you paste in text containing a literal plus sign expecting it to become a space, this tool will leave it as a plus sign rather than silently guessing your intent.
Frequently Asked Questions
What's the actual difference between Query Component and Full URI encoding?
Query Component mode escapes nearly everything except letters, digits, and a small set of safe punctuation, including structural characters like / : ? & =. Full URI mode leaves those structural characters alone since a valid URI legitimately uses them to separate its own parts, only escaping spaces and genuinely unsafe characters.
Why does my query parameter break if it contains an ampersand?
If a value containing a raw & gets placed into a query string without Query Component encoding, the parser misreads it as the start of a new parameter, splitting your value in two. Encoding it with Query Component mode turns it into %26, which safely passes through as data instead of being misread as structure.
Why does decoding sometimes fail with an error?
Decoding fails if a % isn't followed by two valid hex digits, or if the percent-encoded bytes don't reassemble into valid UTF-8, which can happen if an encoded sequence was truncated or corrupted during a copy-paste. This tool catches both cases and shows one clear error message.
Why do some URLs use + for spaces instead of %20?
Both encoding modes here use %20, the correct URI-spec representation for spaces. HTML form submissions use a separate, older convention (application/x-www-form-urlencoded) that encodes spaces as + instead, which is why a query string from a form submission may need an extra conversion step before standard percent-decoding.
Should I always use Query Component mode to be safe?
For a single value destined for a query string, yes. Full URI mode is specifically for encoding an entire URL that already contains its own legitimate structural characters (like the : and / in "https://"), which Query Component mode would incorrectly escape and break.
What does the Swap button do?
It moves the current output into the input box and flips between Encode and Decode mode, a quick way to verify a round trip, encoding text and then swapping to decode should return your original input exactly.