URL Encoder / Decoder Online

URLs can only contain a limited set of ASCII characters. RFC 3986 defines unreserved characters (A-Z, a-z, 0-9, -, _, ., ~) that can appear as-is in URLs. All other characters must be percent-encoded to avoid ambiguity.

Without encoding, characters like & and = would be confused with URL structure (query parameter separators). Spaces, non-ASCII characters, and special symbols must all be encoded to create valid URLs.

Reserved characters (:, /, ?, #, [, ], @, !, $, &, ', (, ), *, +, ,, ;, =) have special meaning in URLs. They should only be encoded when used outside their reserved purpose — for instance, a / in a query parameter value must be encoded as %2F.

Unreserved characters (letters, digits, -, _, ., ~) never need encoding. Encoding them is valid but unnecessary and makes URLs longer.

Use encodeURI() when encoding a complete URL — it preserves ://, ?, #, & and other structural characters. Example: encodeURI('https://example.com/path?q=hello world') gives 'https://example.com/path?q=hello%20world'.

Use encodeURIComponent() when encoding a single parameter value — it encodes everything including & and =. Example: encodeURIComponent('price=10&tax=2') gives 'price%3D10%26tax%3D2'. This is what you need for form data and API parameters.

Double encoding is the most common mistake: encoding an already-encoded URL turns %20 into %2520. Always check if your input is already encoded before encoding it again.

The + sign is another source of confusion. In query strings (application/x-www-form-urlencoded), + means space. But in the path component of a URL, + is literal. decodeURIComponent does NOT decode + as space — you need to replace + with %20 first if dealing with form data.