About URL Encoder
URL Encoder applies percent-encoding to any string so it's safe to drop into a URL path, query parameter, fragment or form-encoded body. The decoder reverses the process and handles plus-as-space (form encoding), already-encoded sequences, and double-encoded mistakes. A dedicated Query String parser splits a full URL or query into name/value pairs in a table you can edit — change a value and the rebuilt URL appears below. The whole thing runs locally using the browser's native encodeURIComponent / URL APIs.
- No uploads
- Browser-only
- Works offline
- 100% free
How it works
- 1
Paste your string
Drop in a raw value (e.g. an email, search term or filename) or a complete URL with parameters you want to inspect.
- 2
Encode or decode
Encode runs encodeURIComponent so every non-unreserved char becomes %XX. Decode reverses it and tolerates malformed or double-encoded input gracefully.
- 3
Edit query parameters
Switch to the Query Parser to break a URL into editable name/value pairs. Edit, add, or delete a row and the rebuilt URL updates live below the table.
What percent-encoding is and why it exists
URLs are restricted to a small, safe set of ASCII characters, so any character outside that set — a space, an accent, a slash that is data rather than a path separator — must be percent-encoded: replaced by a % followed by its byte value in hexadecimal. A space becomes %20, an ampersand becomes %26, and a non-ASCII character is first encoded as UTF-8 and then each byte percent-encoded (é becomes %C3%A9). This is the mechanism that lets arbitrary text travel safely inside a URL without breaking its structure, and it is defined precisely in RFC 3986.
Reserved vs unreserved characters
RFC 3986 sorts characters into two groups, and the distinction is the whole game. Unreserved characters are always safe to leave as-is. Reserved characters have structural meaning — they delimit the parts of a URL — so whether they must be encoded depends on whether you mean them as a delimiter or as literal data. An ampersand between query parameters is structure; an ampersand inside a value ("Johnson & Johnson") is data and must become %26, or it will be misread as the start of a new parameter.
| Category | Characters | Encode inside a value? |
|---|---|---|
| Unreserved | A-Z a-z 0-9 - _ . ~ | Never — always safe literal |
| Sub-delimiters | ! $ & ' ( ) * + , ; = | Yes — they have meaning in queries |
| Gen-delimiters | : / ? # [ ] @ | Yes — they separate URL components |
| Space | (space) | Yes — %20 (or + in form bodies) |
Only A-Z, a-z, 0-9 and - _ . ~ are universally safe to leave unencoded anywhere in a URL.
encodeURIComponent vs encodeURI
JavaScript ships two functions and picking the wrong one is the most common URL bug. encodeURIComponent encodes a single piece — a query value, a path segment — and escapes the reserved characters / ? : @ & = + $ # that would otherwise be read as structure. encodeURI encodes a whole URL and deliberately leaves those delimiters alone so the URL still works. The rule is simple: use encodeURIComponent on each value you drop into a query string or path, and use encodeURI only on a complete URL you are passing through untouched.
Get this backwards and you create silent failures. Running encodeURI over a value that contains an & or = leaves them unescaped, so a value like "a=b&c=d" injects extra parameters into your query. Conversely, neither function escapes a few characters that can still matter in specific contexts — notably + (which a server may decode as a space) and the characters ! ' ( ) * — so when a value must be unambiguous, encode those explicitly.
Double-encoding and other pitfalls to avoid
- Double-encoding: encoding an already-encoded string turns %20 into %2520 (the % itself gets escaped to %25). Encode exactly once, at the moment you build the URL — never re-encode a value that arrived already encoded.
- Forgetting to decode: data read from location.search or a route parameter is still encoded. Decode it once with decodeURIComponent before you display, compare or store it, or %20 leaks into your UI.
- The plus-sign trap: in a query string + can mean a literal plus or a space depending on who decodes it. application/x-www-form-urlencoded form bodies use + for space; percent-encoding uses %20. Be explicit and encode a literal + as %2B.
- Encoding the whole URL by mistake: passing a full https:// URL through encodeURIComponent escapes the :// and ? too, producing a string that is no longer a usable link — only encode the parts, or use encodeURI for the whole.
- Reversibility checks: encoding then decoding should return your exact original string. If it does not, you have either double-encoded or used mismatched encode/decode functions. Pair this with Base64 when you need binary-safe transport rather than URL-safe text.
Related guides
All guidesFrequently asked questions about URL Encoder
What's the difference between encodeURI and encodeURIComponent?
encodeURI preserves URL-structural characters like /, ?, #, & — so it's safe for encoding a full URL where you don't want those to be mangled. encodeURIComponent encodes everything except unreserved chars — it's the right choice for query parameter values and path segments. This tool uses encodeURIComponent by default and exposes encodeURI as a secondary mode.
Does it handle plus-as-space form encoding?
Yes. application/x-www-form-urlencoded (the format browsers send when you submit a form) encodes space as + rather than %20. Toggle Form mode and the encoder will emit + for space, and the decoder will treat + as space — matching what server frameworks like Express and Django expect.
Can I decode a double-encoded string?
Yes — click Decode twice. A double-encoded space looks like %2520 (where %25 is the encoded percent sign). The decoder doesn't guess depth automatically because aggressive decoding can corrupt strings that legitimately contain percent signs, so it leaves the call up to you.
Privacy, offline use, browser support, and pricing questions are answered on the site-wide FAQ.