URL Encoder / Decoder

URL encoding, formally percent-encoding, is the mechanism RFC 3986 defines for representing characters in a URI that fall outside the small set permitted in URI syntax. Every encoded byte appears as a percent sign followed by two uppercase hex digits — so a space becomes %20, an ampersand %26, an at sign %40. Multibyte characters (Unicode code points above U+007F) are encoded as their UTF-8 byte sequence, each byte percent-encoded in turn.

JavaScript provides two complementary functions and this tool exposes both. encodeURIComponent encodes every character that is not in the small unreserved set (A-Z, a-z, 0-9, hyphen, underscore, period, exclamation, tilde, asterisk, single quote, parentheses). It is the right choice for values you intend to drop into a query parameter, a path segment, or a form field, because it escapes the structural characters &, =, /, ?, # that would otherwise be misinterpreted as URI syntax.

encodeURI is the gentler cousin. It assumes the input is already a complete URL and so preserves the structural characters that make a URL parseable: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. Use it when you have a free-form string that resembles a URL and want to make it transport-safe without breaking its structure. Crucially, encodeURI does not encode &, =, or ? — feeding user input through encodeURI when you meant encodeURIComponent is one of the most common sources of broken pagination links.

There is a subtle but important difference between %20 and +. Both decode to a space, but they belong to different specs. RFC 3986 percent-encoding always uses %20. The application/x-www-form-urlencoded media type — what HTML forms POST by default and what URLSearchParams emits in the browser — uses + for spaces. JavaScript's encodeURIComponent follows RFC 3986 (%20); URLSearchParams.toString uses form-urlencoded (+). When debugging encoding issues, identify which spec is in play.

Decoding is the reverse: decodeURIComponent walks the string, replaces every %XX with the corresponding byte, and reinterprets the byte stream as UTF-8. Malformed input — a stray % not followed by two hex digits, or a sequence that does not produce valid UTF-8 — throws URIError. The tool surfaces those errors so you can find the bad byte instead of silently producing mojibake.

Common encoding gotchas in production: don't double-encode (passing already-encoded text through encodeURIComponent again produces sequences like %2520 for what should be %20); don't trust the browser to encode for you when you build URLs by string concatenation in fetch calls; and watch out for the literal plus sign in user input — it must be encoded as %2B in form data or it will be silently turned into a space on the receiving end. The URL and URLSearchParams APIs handle most of this correctly when used in their canonical form.

All processing in this tool happens through the four built-in functions (encodeURI, encodeURIComponent, decodeURI, decodeURIComponent). Nothing leaves the browser, nothing is logged, and the bundle is tiny because no library is involved.