URL encoding turns reserved characters (?, &, =, #, spaces, anything non-ASCII) into safe %xx byte sequences. The most common bug we see in production codebases is using encodeURI (which preserves path-reserved chars) where encodeURIComponent (which doesn't) is meant. This tool calls the latter — the right choice for query parameter values and path segments you control.
URL encode & decode
Percent-encoding turns reserved characters into safe URL bytes. The most common mistake is using encodeURI (path) where you meant encodeURIComponent (query value).
URL encode & decode
Percent-encode query values or decode escaped strings. We use encodeURIComponent, the right call for query parameters and path segments.
Plain text
Encoded
topic%3Dperformance%26q%3DCore%20Web%20Vitals%20%26%20you
Common use cases
Debugging a query string
Paste a broken URL, decode it, find the offending value, fix it at the source.
Encoding a value for a redirect
OAuth flows, password reset links, deep links — anything that nests one URL inside another needs careful encoding.
Reading server logs
Encoded paths in access logs are easier to grep when you can decode them inline — especially when the path carries user-supplied search terms.
How to use this tool
- 1 Toggle Encode or Decode.
- 2 Paste your text — we update the result live.
- 3 Copy and paste into your URL, your test, or your bug report.
Frequently asked questions
encodeURI vs encodeURIComponent — which one?
encodeURI leaves ?, &, =, #, /, : alone — appropriate when you’re encoding a whole URL. encodeURIComponent encodes everything that isn’t unreserved — appropriate when you’re building a single value into a URL. We use the latter.
Does this handle Unicode?
Yes. Multi-byte characters are encoded to their UTF-8 byte sequence; decoding round-trips back to the same string.
What about + for spaces?
That’s an older application/x-www-form-urlencoded convention, not the modern percent-encoding rule. We always emit %20 — valid in every URL context, unambiguous on the decode side.