URL encode or decode text for safe use in URLs
URLs are ASCII-only by specification (RFC 3986), which is why every non-ASCII character and many ASCII characters with structural meaning must be percent-encoded: the character is replaced by `%XX` where XX is the hex representation of its UTF-8 byte value. A space becomes `%20`an ampersand in a parameter value becomes `%26`and a non-ASCII character like `é` becomes `%C3%A9` (two bytes because é is encoded as two bytes in UTF-8). Without this encoding, a query string like `?name=alice&smith` would parse as two parameters (name=alice, smith=empty), breaking whatever logic depended on "alice&smith" being a single name. There are two encoding modes that cover different use cases. encodeURI() is for encoding an entire URL where you want to preserve structural characters: `/``?``&``:``=``#` stay as literal characters because they have meaning in URL structure. encodeURIComponent() is for encoding individual components (a single parameter value or path segment) where you want everything non-alphanumeric escaped so it cannot be mistaken for structural syntax. Using encodeURI when you needed encodeURIComponent is the most common URL-encoding bug and produces URLs that look right but parse wrong when the value contains `&``?`or `#`.
Initializing in your browser…
Encode and decode text or files to/from Base64
Decode and inspect JSON Web Tokens (JWT). View header, payload, claims, expiration status, and signature without needing the secret key
Convert between Unix/Epoch timestamps and human-readable dates. Supports seconds and milliseconds with timezone information
You are building a query string by hand and a value contains spaces, an ampersand, and an accented character that keep breaking the URL.
Raw query value
name=John Doe&city=São Paulo
Percent-encoded
name%3DJohn%20Doe%26city%3DS%C3%A3o%20Paulo
Characters with meaning in a URL (`=`, `&`, space) or outside ASCII (`ã`) must be percent-encoded so they are treated as data, not structure. `ã` becomes `%C3%A3` because it is first encoded as its two UTF-8 bytes. Decode the wrong way and "São" turns to mojibake, the tool handles the UTF-8 round-trip correctly in both directions.
URLs are ASCII-only by specification (RFC 3986), which is why every non-ASCII character and many ASCII characters with structural meaning must be percent-encoded: the character is replaced by `%XX` where XX is the hex representation of its UTF-8 byte value. A space becomes `%20`an ampersand in a parameter value becomes `%26`and a non-ASCII character like `é` becomes `%C3%A9` (two bytes because é is encoded as two bytes in UTF-8). Without this encoding, a query string like `?name=alice&smith` would parse as two parameters (name=alice, smith=empty), breaking whatever logic depended on "alice&smith" being a single name. There are two encoding modes that cover different use cases. encodeURI() is for encoding an entire URL where you want to preserve structural characters: `/``?``&``:``=``#` stay as literal characters because they have meaning in URL structure. encodeURIComponent() is for encoding individual components (a single parameter value or path segment) where you want everything non-alphanumeric escaped so it cannot be mistaken for structural syntax. Using encodeURI when you needed encodeURIComponent is the most common URL-encoding bug and produces URLs that look right but parse wrong when the value contains `&``?`or `#`.
Some specific encoding edge cases that catch people out. Spaces are encoded as `%20` in standard URL encoding but as `+` in application/x-www-form-urlencoded (the format HTML forms submit by default). A decoder needs to know which context it is reading; a naive decoder that treats `+` as literal plus will mangle form-encoded data, and one that always treats `+` as space will mangle URL paths that legitimately contain `+`. This tool handles both, but in your own code, JavaScript's decodeURIComponent does NOT decode `+` as space, you have to pre-replace `+` with `%20` before calling it if the input is form-encoded.
Unicode handling is specified by RFC 3986 and its successors: non-ASCII characters should be UTF-8 encoded byte-by-byte and then percent-encoded. The multi-byte character `中` (U+4E2D) is UTF-8 as `E4 B8 AD` and URL-encodes to `%E4%B8%AD`. Older URL encoders sometimes used Latin-1 or the current system encoding, which produced URLs that worked on one system and broke on others. Modern browsers and servers all use UTF-8; if you encounter legacy non-UTF-8 encoding in the wild, it is a bug in the producing system.
The "reserved" and "unreserved" character sets are worth knowing. Unreserved characters (letters, digits, `-``.``_``~`) never need encoding in any position. Reserved characters (`:``/``?``#``[``]``@``!``$``&``'``(``)``*``+``,``;``=`) have specific structural meaning and only need encoding when they appear in a context where that meaning would cause misparsing. encodeURI preserves reserved characters because it assumes you want URL structure intact; encodeURIComponent escapes reserved characters because it assumes you are encoding a value that should not affect URL structure. Both handle unreserved and non-ASCII characters identically.
Safely encode parameter values that may contain spaces, ampersands, or other reserved characters.
Decode URLs from server logs or browser dev tools to read the actual parameter values.
Encode non-ASCII characters so URLs work correctly across all browsers and servers.
encodeURI preserves URL structure characters (like / and :), while encodeURIComponent encodes everything except unreserved characters, use the latter for individual parameter values.
HTML form submissions use + for spaces (application/x-www-form-urlencoded), while standard percent-encoding uses %20. Both are valid in different contexts.
Conversions run on your device in JavaScript. The values you enter are never sent over the network.