URL Encoder & Decoder

What this tool does

URLs can only contain a limited set of ASCII characters. Anything else — spaces, Chinese characters, &, =, ?, # and most punctuation — has to be percent-encoded as %XX bytes before it can travel safely in a link, a form submission or an API call. This page does that encoding in both directions and, unlike most encoders, also breaks the result down: paste any URL or query string and the parameters appear as a decoded key–value table, so you can read a tracking link or an OAuth redirect at a glance.

Text is treated as UTF-8, so 中文 becomes %E4%B8%AD%E6%96%87 exactly as browsers and servers expect. Decoding is tolerant: a stray % that is not a valid escape is left alone instead of throwing an error, and + is treated as a space when you are decoding form data.

Component vs. whole-URL encoding

Encode component is JavaScript's encodeURIComponent: it escapes everything except letters, digits and -_.!~*'(). Use it for a single value that goes into a query parameter, a path segment or a form field. Encode URL is encodeURI: it leaves the structural characters :/?#[]@!$&'()*+,;= untouched so that a complete address stays a valid address, and only escapes spaces and non-ASCII text. Using the wrong one is the classic bug — encodeURIComponent on a full URL turns every / into %2F and breaks the link, while encodeURI on a value containing & silently splits it into two parameters.

The Space as + option switches between %20 (RFC 3986, used in URLs) and + (application/x-www-form-urlencoded, used in HTML form bodies and many legacy query strings). Both decode correctly here; choose the encoding your target expects.

Common mistakes

Double encoding: encoding an already-encoded value turns %20 into %2520 and the server sees a literal %20. If your decoded output still contains %XX sequences, decode once more. Forgetting to encode & or # inside a value truncates the parameter. Encoding the whole URL with encodeURIComponent breaks the scheme and slashes. Mixing + and %20 conventions between client and server produces plus signs in user names. Finally, percent-encoding is not encryption or obfuscation — a value is fully readable after decoding, so never rely on it to hide tokens; if you need opacity for a payload, Base64 is the usual transport encoding, and it too is trivially reversible.

Background: where percent-encoding comes from

Percent-encoding was defined with the first URL specification, RFC 1738 (1994), written by Tim Berners-Lee and colleagues, and refined in RFC 3986 (2005), which is the current standard for URI syntax. The % escape mechanism predates UTF-8's dominance, which is why older systems sometimes encode bytes in Latin-1 or Shift-JIS and produce mojibake when decoded as UTF-8 — the HTML5 URL Standard (WHATWG) finally mandated UTF-8 for new encoding. The + for space convention comes from the separate HTML forms specification, not from the URL standard, which is the historical reason two space encodings coexist today.

Where it is used

Building API requests by hand (search terms, filters, callback URLs), debugging tracking links from ad platforms (utm_source, gclid, fbclid), reading OAuth and SSO redirects (redirect_uri, state, scope), constructing mailto: and tel: links with subject lines and bodies, sharing links that contain Chinese or Japanese paths, and inspecting webhook payloads sent as form data. The parameter table is handy for pasting a long URL from a support ticket and seeing exactly what was requested. Values inside a query string are often JSON or Base64 — decode here first, then paste the value into the matching tool.

Frequently asked questions