Encode a whole URL or a single query value with the right mode — component or full — and decode percent-escapes back to the text they came from, in your browser. Runs entirely in your browser — your numbers never leave this device.
| Character | Component mode | Full-URL mode |
|---|---|---|
| Space | %20 — escaped | %20 — escaped |
| & | %26 — escaped | & — kept (separates parameters) |
| = | %3D — escaped | = — kept (joins a name to its value) |
| ? | %3F — escaped | ? — kept (opens the query string) |
| / | %2F — escaped | / — kept (separates path segments) |
| # | %23 — escaped | # — kept (opens the fragment) |
URLs may only contain a small set of safe characters, so everything else travels as percent-encoding: the character's bytes written as % followed by two hexadecimal digits — a space becomes %20, an ampersand %26. Text beyond ASCII is encoded as UTF-8 first, which is why a single ✓ turns into three escapes, %E2%9C%93. Decoding runs the same rules backwards, turning each %XX back into its byte and reading the bytes as UTF-8.
The one decision on this page is the mode, and the table below is the whole difference. Full mode (encodeURI) is for a complete URL you want to keep working: it escapes spaces and stray characters but keeps the characters that give the URL its structure — the : // of the scheme, the ? that opens the query, the & between parameters. Component mode (encodeURIComponent) is for one value going inside a URL, such as a search term or a redirect target: it escapes those same structure characters, because inside a value an & must not start a new parameter and a ? must not start a query. Using full mode on a value is the classic bug — the value's own & and = silently split it into phantom parameters.
Two traps sit next to that one. A + in a query string is read as a space by form decoding, even though this tool writes spaces as %20 — both forms decode to a space, but a literal plus sign must be encoded as %2B to survive. And encoding an already-encoded string double-encodes it: %20 becomes %2520, which decodes back to %20, not to a space. Everything runs in your browser; the URLs and values you paste are never uploaded.
Ask what the text is. If it is a whole URL that must keep working, choose full mode. If it is one value — a search term, a name, a redirect address — that will sit inside a URL, choose component mode. The worked examples show the same characters treated both ways: a b&c=d becomes a%20b%26c%3Dd as a value, while a full URL keeps its & and = readable.
Both decode to a space in query strings. %20 is the general percent-encoding and is valid everywhere in a URL; + meaning space is a convention of HTML form submissions (application/x-www-form-urlencoded) and only applies inside query values. A literal plus sign in your data must be sent as %2B, or a form decoder will hand the other side a space.
The string was encoded twice. Double-encoded text turns a space into %2520 — an escaped percent sign followed by 20 — and one decode pass correctly returns %20. Decode it a second time to reach the original text, and fix the source so it encodes once.
The unreserved set: letters A–Z and a–z, digits, and the marks - _ . ~ (plus, in component mode, a few extras such as ' and ! that JavaScript's encoder leaves alone). Everything structural or unsafe — spaces, quotes, <, >, non-ASCII text — travels as %XX escapes.
Because the escapes do not form valid UTF-8 bytes — a lone %E2 with its continuation bytes cut off, or a % followed by non-hex characters. That happens when an encoded string was truncated (a common copy-paste accident in long URLs) or decoded with the wrong character set. This tool reports the failure instead of inventing replacement characters.
No. Encoding and decoding run in your browser only — URLs often carry tokens and private parameters, and they never leave your device here.
More in Developer Tools · Browse all tools