How URL Encode / Decode works
URL Encode / Decode converts characters to and from percent-encoded form (%xx) per RFC 3986. Letters, digits, and - _ . ~ are never encoded. Spaces become %20 (or + in the legacy application/x-www-form-urlencoded flavour). All other unsafe characters become percent-escaped bytes. Decoding reverses the process and renders UTF-8 text.
How to use
Paste a URL or query string, pick the encoding mode, and read the result. Common use cases: embed user input in a URL, decode %xx-encoded links from logs, normalise query parameters.
Frequently asked questions
Should I use "+" or "%20" for spaces?
Both are valid in different contexts. %20 is the RFC 3986 standard and works everywhere. + is the legacy application/x-www-form-urlencoded form and is only honoured by HTML form submissions and a few server-side parsers. When emitting query strings for web APIs, prefer %20.
Does the tool validate the URL itself?
No — it only handles percent-encoding. The structure of the URL (scheme, host, path) is left as you typed it. Use a URL builder or validator if you need to assemble a full URL.
Why did decoding turn %E4%B8%AD into one Chinese character?
Those three percent-escapes are the UTF-8 bytes for 中. The decoder reads the byte sequence, recognises it as valid UTF-8, and emits the character rather than three separate codepoints.
Are reserved characters like "?" and "&" encoded?
No by default — they would break URL structure if encoded. The tool leaves unreserved characters alone so your URL stays parsable, and only encodes characters that would otherwise be ambiguous or unsafe.
Is my URL sent to a server?
No. Encoding and decoding are pure JavaScript operations and run locally. Safe to use on URLs that contain session ids or tokens.