URL Encoder / Decoder
Percent-encode strings for safe use in URLs, query parameters, or form bodies. Decode percent-encoded URLs back to plain text. Pick between component encoding and full URL encoding.
How it works
- 1Pick modeEncode or decode.
- 2Pick scopeComponent for values, URI for whole URLs.
- 3ResultUpdates as you type.
Percent-encoding: the rule that makes the web's URLs work
What percent-encoding is
RFC 3986 defines a URI as a string of ASCII characters from a restricted set. Characters outside the safe set — spaces, accents, emoji, non-Latin scripts, special punctuation — must be "percent-encoded" before they can appear in a URL. The encoding is simple: a percent sign followed by two hex digits representing the byte value. A space (0x20) becomes %20. The em-dash (U+2014) is UTF-8 0xE2 0x80 0x94 → %E2%80%94.
Without percent-encoding, every non-ASCII character would either be silently mangled or reject the request. The protocol has worked this way since RFC 1738 (1994) and remains unchanged today.
Reserved vs unreserved characters
The unreserved set — `A-Z a-z 0-9 - _ . ~` — never needs encoding. The reserved set is split in two: gen-delims (`: / ? # [ ] @`) and sub-delims (`! $ & ' ( ) * + , ; =`). Reserved characters have structural meaning in URLs; whether they need encoding depends on where they appear.
Example: an `@` is fine in a path (`/users/foo@bar`) but breaks if it appears in the userinfo (`https://[email protected]/`). A `/` is fine in a path but must be encoded inside a query value (`?file=path%2Fto%2Ffile`).
The two JavaScript functions, in plain English
`encodeURI(s)` treats `s` as a complete URI. It leaves `: / ? # [ ] @ ! $ & ' ( ) * + , ; =` alone — every character that's structurally meaningful in a URL. Use this when you have a URL that contains some non-ASCII characters and you want to make it safe to use as-is.
`encodeURIComponent(s)` treats `s` as a single component to be embedded in a URI. It encodes everything except `A-Z a-z 0-9 - _ . ! ~ * ' ( )`. Use this when building a URL from parts — you don't want a `&` in a value to look like a parameter separator. Rule of thumb: `encodeURIComponent` for values, then concatenate.
Forms and the +/%20 trap
HTML form submissions use a slightly different encoding: `application/x-www-form-urlencoded`. In this MIME type, spaces are encoded as `+`, and `+` itself must be encoded as `%2B`. This is the historical reason JavaScript has `URLSearchParams` separate from `encodeURI*`: `URLSearchParams.toString()` follows the form-urlencoded rules, while `encodeURIComponent` follows RFC 3986.
Mixing these breaks things in subtle ways. A literal `+` in a query value, encoded by `encodeURIComponent`, comes out as `+` (it's in the safe set). On the server, a form-urlencoded parser sees that `+` and turns it back into a space. So if you intentionally have a `+` in user-typed text and you pass it through a form-decoder, it becomes a space. Always be explicit about which encoding rules are in force.
Internationalized URLs (IDN, IRI)
Hostnames with non-ASCII letters (`möbel.de`, `北京.cn`) are technically Internationalized Domain Names (IDN). They're stored in DNS using Punycode (`xn--`-prefixed ASCII), but browsers display them in their original form. Paths and query strings with non-ASCII bytes use percent-encoding as described above.
Modern browsers and HTTP clients handle this transparently. If you're building URLs programmatically and your input may include non-Latin text, make sure your library percent-encodes the path and query (it should — Node's `URL` does, Python's `urllib.parse` does, Go's `net/url` does). Manually concatenating strings is where bugs creep in.
Frequently asked
What's the difference between encodeURI and encodeURIComponent?
`encodeURI` is for full URLs — it leaves characters that are valid in a URL (like /, ?, #, =) untouched. `encodeURIComponent` is for individual components like query-string values — it encodes everything except A-Z, a-z, 0-9, and -_.!~*'(). Use Component for values, URI for whole URLs.
When should I encode space as '+' instead of '%20'?
Only in `application/x-www-form-urlencoded` form bodies (HTML form POSTs). Everywhere else — query strings, paths, fragments — use '%20'. The '+' for space convention is form-specific and not part of RFC 3986.
Why do '#' and '&' need encoding in values?
'#' marks the start of the fragment in a URL. '&' separates query parameters. If they appear in a value unencoded, the URL parser stops or splits early. Always encode them as %23 and %26 in values.
Get new tools first.
One tool per week. No ads. Unsubscribe anytime.