URL Encoder / Decoder

URL encoding (percent-encoding) is one of those things every developer encounters daily but rarely thinks about until something breaks. A misencoded query parameter can silently corrupt data, cause authentication failures, or produce confusing 400 errors.

Why URLs need encoding

URLs can only contain a subset of ASCII characters. Characters outside this set — spaces, non-ASCII Unicode, and reserved characters with structural meaning (?, &, =, /, #) — must be encoded as percent-escaped sequences: `%20` for space, `%26` for &, etc.

encodeURI vs encodeURIComponent

This distinction trips up even experienced developers:

- `encodeURI` is for encoding a complete URL. It preserves structural characters like /, ?, &, = because they have meaning in the URL structure. - `encodeURIComponent` is for encoding a single value within a URL — a query parameter value, a path segment. It encodes everything except letters, digits, and `- _ . ! ~ * ' ( )`. Use this for any value you're inserting into a URL template.

The + vs %20 confusion

In HTML form submission (application/x-www-form-urlencoded), spaces in query strings become +. In URL path segments and per RFC 3986, spaces are %20. This tool follows RFC 3986 (%20 everywhere), which is safer across contexts.

Common debugging scenarios

- API call works in Postman but fails in code: likely a missing or double-encoded parameter. - Query string value is truncated: an unencoded & in the value is splitting it into two parameters. - Special characters appear garbled: the server decoded the URL in a different encoding (UTF-8 vs Latin-1).