URL Encoder & Decoder

JavaScript ships two URL encoding functions because URLs have different escaping rules for different parts. encodeURI is for entire URLs — it leaves reserved characters like /, ?, &, =, # alone because they have structural meaning. encodeURIComponent is for individual values inside a URL — it escapes ALL reserved characters because at that level, a literal & or = in your data would corrupt the URL structure.

Practical rule: use encodeURIComponent on any string you are inserting into a URL component (path segment, query value, fragment). Use encodeURI only when you have a complete URL whose structure is already correct and you just need to handle non-ASCII characters.

• Always encode in component values: space → %20 (or +), &, =, ?, #, /, +, % itself
• Sometimes encode: : @ — fine in paths and queries, escape them in fragments
• Never encode (unreserved per RFC 3986): A-Z, a-z, 0-9, hyphen, period, underscore, tilde
• Special: + means space in application/x-www-form-urlencoded query strings, but means literal + in URL paths. The distinction matters for form submissions vs REST endpoints.
• High-bit bytes (UTF-8 sequences for non-ASCII): always encoded byte-by-byte. "ł" (0xC5 0x82 in UTF-8) becomes %C5%82.

• A URL in your bug report is broken and you need to see what the actual decoded query parameter is.
• You are constructing a deep link or share URL by hand and want to verify the escaping before publishing.
• You are debugging an OAuth flow where redirect_uri must be exactly registered — including identical encoding.
• You are reverse-engineering a third-party API where the docs show URL-encoded examples and you need readable equivalents.

• It will not validate the URL structure. A syntactically encoded but semantically wrong URL (https://example.com/?? not%20a%20parameter) will encode/decode happily without warning that there is something off.
• It will not handle IDN domains. https://exämple.com must be Punycode-encoded (xn--exmple-cua.com) at the DNS level — separate from percent-encoding the path.
• It will not undo double-encoding. If a URL was encoded twice (a common bug when proxies re-encode already-encoded URLs), one decode pass leaves %2520 → %20, and a second pass produces a space. Decode twice if your input came through multiple URL-mangling hops.