URL Encoder / Decoder

Why URLs need encoding

URLs may only contain a limited set of ASCII characters. Spaces, Chinese characters, `&`, `#`, `%`, `+` and non-Latin letters have to be turned into `%XX` escape sequences before they can travel safely through browsers, servers and proxies. This tool does that conversion — and the reverse — instantly.

Component mode vs whole-URI mode

• component (query value) — encodes everything that would break a value: spaces become `%20`, `&` becomes `%26`, `/` becomes `%2F`. Use this when you are putting a value inside a query string or a form field.
• whole URI — keeps URL structure intact (`/`, `?`, `&`, `=`, `#` stay readable) and only escapes characters that are genuinely illegal. Use it on a full URL you want to display or log.

Choosing the wrong mode is the #1 reason a link "works for me" but 404s on the server: in component mode a nested URL gets its `/` and `?` escaped.

Common tasks

• Fixing a link with a space in it (`my file.pdf` → `my%20file.pdf`)
• Reading a messy redirect you copied from devtools
• Building a query parameter by hand
• Decoding tracking links to see what they contain

Notes

• Decoding fails loudly on malformed input (a lone `%`), which usually means the value was double-encoded.
• `+` means a space only in form encoding, not in paths. Decode `application/x-www-form-urlencoded` bodies with care.
• Nothing is uploaded; conversion happens in your browser.

FAQ

Should I use component or whole-URI mode?

For any value going into a query string or form field, use component. For a full URL you want to keep readable, use whole URI.

Why does my link break after encoding?

Almost always a mode problem — component mode escaped the / and ? of a nested URL. Re-encode the whole URL in whole-URI mode, or only encode the value.

Does it handle Chinese characters?

Yes. Non-ASCII characters are UTF-8 encoded first, then percent-escaped, which is what modern servers expect.