Don't double-encode. Encoding an already-encoded string turns %20 into %2520 . If your input shows %XX sequences, decode first. Spaces aren't always %20 . In application/x-www-form-urlencoded bodies, spaces are + . This tool follows the JavaScript encodeURIComponent convention (always %20 ); decode handles both. UTF-8 vs Latin-1. Modern browsers and encodeURIComponent always use UTF-8. Some older systems still produce Latin-1 percent-escapes — those won't round-trip cleanly here. Reserved characters are case-insensitive in the percent-escape but case-sensitive in the decoded result — %2F and %2f both decode to / , but the original character's case is preserved.

Three encodings, three audiences. encodeURI() preserves URL structure (commas, slashes, colons stay literal — for whole URLs). encodeURIComponent() escapes everything except unreserved characters (for query-string values and path segments). encodeURIComponent() then re-allowing slashes is for path segments that legitimately contain slashes. Using the wrong one breaks the URL or produces over-escaped strings the receiver has to clean up. Double-encoding is the silent URL bug. Encoding a string twice produces %2520 where %20 was meant. Most servers decode once, so the second-level escape comes through as literal "%20" in the path. Debug by looking at server logs: if you see "%25" anywhere in a URL that shouldn't have a literal percent sign, double-encoding happened somewhere up the chain. The plus-vs-percent-twenty trap. In a URL path , spaces are always %20 and + is literal "+". In a URL query string , + means space (legacy from form-urlencoded), and %20 also means space. A query parameter with a literal "+" must be encoded as %2B . The number of bugs caused by this single inconsistency is staggering — most "search for X" features that mangle plus signs trace back here. IDN domains need punycode, not percent-encoding. Internationalised domain names (e.g., 例え.テスト ) become xn--r8jz45g.xn--zckzah via punycode before going on the wire. Percent-encoding does not apply to the domain part of a URL. Browsers handle this conversion in the address bar; backend code that constructs URLs from user input often does not. Reserved-character lists differ by URL component. RFC 3986 defines different "reserved" sets for the scheme, authority, path, query, and fragment. A character that's safe in a path segment may need encoding in a query parameter. The encodeURIComponent default is conservative (escapes more than necessary in some contexts), which is usually right — over-escaping is harmless, under-escaping is a security vulnerability.

URL Encoder / Decoder

Percent-encode strings for URLs or decode percent-encoded ones back to plain text.

Mode

Scope

Input

Output

Enter input above to see the result.

What URL encoding does

URLs and HTTP headers are restricted to a small ASCII subset. Anything outside that set — including spaces, accented letters, emoji, and several reserved punctuation characters — has to be percent-encoded: replaced by % followed by two hex digits per byte. café becomes caf%C3%A9 (UTF-8). Decoding reverses that.

When to use which scope

Component — pick this for individual values you'll splice into a URL: query-string values, path segments, fragment text, header values. Encodes the structural characters / ? # & = + so they don't accidentally end up parsed as URL syntax.
Full URI — pick this for a whole URL you want to clean up. Preserves / ? # & = + as URL structure, only encodes illegal characters (spaces, non-ASCII, etc.).

Common gotchas

Don't double-encode. Encoding an already-encoded string turns %20 into %2520. If your input shows %XX sequences, decode first.
Spaces aren't always %20. In application/x-www-form-urlencoded bodies, spaces are +. This tool follows the JavaScript encodeURIComponent convention (always %20); decode handles both.
UTF-8 vs Latin-1. Modern browsers and encodeURIComponent always use UTF-8. Some older systems still produce Latin-1 percent-escapes — those won't round-trip cleanly here.
Reserved characters are case-insensitive in the percent-escape but case-sensitive in the decoded result — %2F and %2f both decode to /, but the original character's case is preserved.

Expert notes

Three encodings, three audiences. encodeURI() preserves URL structure (commas, slashes, colons stay literal — for whole URLs). encodeURIComponent() escapes everything except unreserved characters (for query-string values and path segments). encodeURIComponent() then re-allowing slashes is for path segments that legitimately contain slashes. Using the wrong one breaks the URL or produces over-escaped strings the receiver has to clean up.
Double-encoding is the silent URL bug. Encoding a string twice produces %2520 where %20 was meant. Most servers decode once, so the second-level escape comes through as literal "%20" in the path. Debug by looking at server logs: if you see "%25" anywhere in a URL that shouldn't have a literal percent sign, double-encoding happened somewhere up the chain.
The plus-vs-percent-twenty trap. In a URL path, spaces are always %20 and + is literal "+". In a URL query string, + means space (legacy from form-urlencoded), and %20 also means space. A query parameter with a literal "+" must be encoded as %2B. The number of bugs caused by this single inconsistency is staggering — most "search for X" features that mangle plus signs trace back here.
IDN domains need punycode, not percent-encoding. Internationalised domain names (e.g., 例え.テスト) become xn--r8jz45g.xn--zckzah via punycode before going on the wire. Percent-encoding does not apply to the domain part of a URL. Browsers handle this conversion in the address bar; backend code that constructs URLs from user input often does not.
Reserved-character lists differ by URL component. RFC 3986 defines different "reserved" sets for the scheme, authority, path, query, and fragment. A character that's safe in a path segment may need encoding in a query parameter. The encodeURIComponent default is conservative (escapes more than necessary in some contexts), which is usually right — over-escaping is harmless, under-escaping is a security vulnerability.