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 `#`.
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.
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.
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.