Skip to content

URL Encoder / Decoder

Encoded output

Estimates for educational purposes — not financial, medical, or legal advice. See terms.

Percent-encoding (also called URL encoding) is the mechanism that lets arbitrary text appear safely inside a URL. This tool encodes plain text to percent-encoded form and decodes percent-encoded strings back to text.

encodeURIComponent vs encodeURI

There are two standard JavaScript encoding functions, and they behave very differently.

encodeURIComponent (the Component mode) is the stricter one. It encodes every character that is not an unreserved character — meaning it encodes reserved characters like ?, &, =, /, :, and #. Use it whenever you are embedding a value inside a URL, such as a query string parameter value or a path segment, because those characters have structural meaning in URLs and must not appear unencoded.

encodeURI (the Whole URL mode) is designed for complete URLs. It leaves the structural characters intact — :, /, ?, #, &, =, @ — so the URL remains valid. It encodes only characters that are illegal in URLs, like spaces and non-ASCII characters. Use it when you have a full URL that just needs its spaces and non-ASCII characters escaped.

Concretely: if your URL is https://example.com/search?q=hello world, pass it to Whole URL mode and get https://example.com/search?q=hello%20world. If you only have the value hello world that needs to go into the q parameter, pass it to Component mode and get hello%20world (same in this case, but Component mode would also escape a ? or & in the value, while Whole URL mode would not).

The + versus %20 history

Two conventions exist for encoding spaces in URLs. The modern RFC 3986 standard uses %20. The older application/x-www-form-urlencoded convention — used by HTML forms submitted with method="GET" — encodes spaces as +. The two are not interchangeable in all contexts: + means a literal plus sign in a path segment but a space in a form-encoded query string.

When decoding a URL that came from an HTML form submission, enable the ”+ as space” toggle. For everything else, leave it off.

Example

Input (Component mode): Hello World! price=10€

Encoded: Hello%20World!%20price%3D10%E2%82%AC

The space becomes %20, = becomes %3D, and the euro sign (€, Unicode U+20AC) becomes %E2%82%AC — its three UTF-8 bytes encoded as three percent sequences.

Unicode and special characters

All Unicode characters are supported. Encoding converts each character to its UTF-8 byte sequence and percent-encodes each byte. Decoding reverses the process: the byte sequence is reassembled and decoded as UTF-8. Emoji, CJK characters, accented Latin letters, and any other Unicode codepoint round-trip correctly.

For a different “encoding” target, the Base64 encoder / decoder produces the 4-char-per-3-byte form (used in data URLs, JWTs, and email). For HTML-escaping special characters in rendered text instead, the HTML entities encoder / decoder covers that axis.

Frequently asked questions

What is the difference between encodeURIComponent and encodeURI?

encodeURIComponent encodes everything except unreserved characters (letters, digits, - _ . ! ~ * ' ( )), making it safe for query string values and path segments that should not be interpreted as URL delimiters. encodeURI is designed for whole URLs — it preserves the structural characters : / ? # & = @ so the URL stays valid as a URL. Use encodeURIComponent when embedding a value inside a URL; use encodeURI when you have a complete URL that just needs its non-ASCII characters escaped.

What is the difference between + and %20 for spaces?

Both represent a space, but in different contexts. %20 is the correct percent-encoding for a space character per RFC 3986 and works everywhere. The + convention for spaces comes from the older application/x-www-form-urlencoded format used by HTML forms — when a browser submits a form with method=GET, spaces in field values become + in the query string. Modern APIs prefer %20. If you are reading a form submission, enable the '+ as space' toggle; otherwise leave it off.

Why does URL encoding use percent signs?

Percent-encoding (RFC 3986) represents each non-ASCII or reserved byte as a percent sign followed by two hexadecimal digits, e.g. %20 for a space (byte 0x20) or %C3%A9 for é (UTF-8 bytes 0xC3 and 0xA9). The percent sign itself is encoded as %25. This scheme ensures any arbitrary text can be safely embedded in a URL without ambiguity about delimiters.

When does decoding fail?

Decoding fails when the percent sequence is malformed — for example %GG (not valid hex), a lone % with fewer than two characters after it, or a sequence that is syntactically valid but forms invalid UTF-8. The tool returns a clear error message in those cases rather than silently producing garbage.

Does this tool handle Unicode characters?

Yes. When encoding, multi-byte Unicode characters like é, 日, or emoji are first converted to their UTF-8 byte sequences, then each byte is percent-encoded. When decoding, the percent-encoded byte sequences are reassembled and interpreted as UTF-8, so the original Unicode text is recovered correctly.