URL encoder, decoder. Param vs full-URL modes.
Paste a URL or encoded value. Auto-detect direction. Toggle between encodeURIComponent (per-parameter) and encodeURI (full URL). Query-string parser breaks the URL into name / value pairs. Browser-only.
Paste a URL or encoded value. Auto-detect handles either direction. Toggle between encodeURIComponent (per-parameter, escapes structural characters) and encodeURI (full URL, preserves structure). When the input is a URL with a query string, the parser breaks it into name / value pairs.
// output appears here
| Key | Decoded value | Encoded form |
|---|
Reference: common encodings
Per RFC 3986. Unreserved characters (A-Z, a-z, 0-9, -, _, ., ~) are never escaped.
Privacy: encoding happens in your browser. Nothing is sent or logged.
Three encode modes. Three jobs.
encodeURIComponent — for parameter values. Use when the input is a single value going into a URL slot — a query parameter value, a path segment value, a fragment identifier. It escapes / : ? & = # so a value containing those characters doesn't break URL parsing. The most common need: encoding a search query that may contain ampersands or slashes before appending it to a URL.
encodeURI — for whole URLs. Use when the input is already a complete URL with correct structure but might contain spaces or unicode. Preserves / : ? & = # so the structure stays parseable. Don't use this on parameter values — it will leave the structural characters unescaped, breaking the parse. Most useful for fixing up a URL with spaces in the path that should have been escaped at the source.
form (space-as-plus) — for HTML form submission. The application/x-www-form-urlencoded variant used in classic HTML form submission. Identical to encodeURIComponent except space encodes as + instead of %20. Rarely needed today — modern fetch / XHR uses %20 — but still required when constructing a form-encoded body manually for an old CGI-style endpoint.
Four jobs this tool covers.
Job 1: Inspect a tracking URL. Paste a long marketing URL with multiple UTM parameters and a referrer URL embedded in another parameter. The query parser breaks it into a clean key / value table — names, decoded values, encoded form. Faster than reading %26%3D%2F sequences in a long URL by eye.
Job 2: Build a search-query URL. Take a phrase that may contain ampersands, slashes, or quotes — "red shoes" size 10 & under $50 — encode in component mode, drop into a search URL slot. The result is the safe value Google / Amazon / your search would use to send that exact query. Pair with our UTM Builder for the marketing-tagging side.
Job 3: Decode an OAuth redirect. OAuth flows return tokens, scopes, and state in the URL fragment or query string — usually URL-encoded. Paste the redirect URL, the parser surfaces each parameter cleanly. Useful for debugging "why is the access token coming back malformed" and finding where the encoding went wrong.
Job 4: Cleanup a copy-paste URL. Some chat apps and email clients double-encode URLs when you paste them. Paste the over-encoded URL, hit decode, you'll see the original. If decode produces a still-encoded string (e.g., %2520 → %20 → space), decode again. Three passes max usually clears any layered encoding.
Six questions users ask.
What's the difference between encodeURIComponent and encodeURI?
encodeURI preserves URL-structural characters (slash, colon, hash, question mark, ampersand) so it's safe to use on a complete URL — the structure stays parseable. encodeURIComponent escapes all reserved URI characters including slash and ampersand, so it's safe to use on a single parameter value that could contain them. Use encodeURI for full URLs that already have correct structure but need spaces and unicode escaped. Use encodeURIComponent for individual query-parameter values, fragment identifiers, or any string going into a URL slot. The wrong choice causes the most common URL bug: an ampersand inside a parameter value being interpreted as a parameter separator.
Why does space encode as %20 sometimes and + other times?
Two encodings, both legal in different contexts. RFC 3986 (the URI standard) says space should be %20 — universally safe in URLs. The application/x-www-form-urlencoded spec used in HTML form submission encodes space as +. Most server-side parsers handle both, but +-as-space is only correct in the query string portion of a URL, not in the path. We default to %20 because it's the universally-correct form. Use the form-encoded toggle only if you're building a manual form-submission URL.
How does the query-string parser work?
When the input looks like a URL with a ? query string, we split it into pairs and decode each value. Useful for inspecting tracking-link payloads, OAuth redirects, or anything with multiple URL parameters. The parsed table shows each parameter name, the decoded value, and the encoded form so you can see what was being sent. We handle repeated keys (?tag=a&tag=b becomes [a, b]), escaped equals inside values, and URL fragments separately.
What characters get escaped?
Per RFC 3986, the reserved characters are gen-delims (: / ? # [ ] @) and sub-delims (! $ & ' ( ) * + , ; =). Unreserved characters (A-Z, a-z, 0-9, hyphen, underscore, period, tilde) are never escaped. Anything outside the ASCII printable range (unicode) is always escaped. encodeURI keeps the gen-delims and sub-delims unescaped (so URL structure works); encodeURIComponent escapes all reserved characters except the unreserved set. The reference panel shows the lookup table for common characters.
Will this handle internationalized domain names (IDN)?
We percent-encode the path and query parts but do not Punycode the hostname. Modern browsers do Punycode automatically when you hit Enter on a unicode hostname (xn--…), but this tool focuses on path / query encoding which is the more common need. If you specifically need to convert a unicode hostname like münchen.de to its Punycode form (xn--mnchen-3ya.de), use Node's built-in url.domainToASCII or any Punycode library.
Is the URL I paste sent anywhere?
No. We use the browser's native encodeURIComponent / decodeURIComponent and URL APIs — all run client-side. The page is static HTML; the only network request is the initial page load. Safe for URLs containing API keys, tokens, or session identifiers in the query string.