URL Encode / Decode
URL encoding, also called percent-encoding, converts characters that aren't safe to use
in a URL into a format every browser and server can transmit reliably, as defined in
RFC 3986.
Each unsafe character is replaced with a % followed by its two-digit
hexadecimal byte value — a space becomes %20, and &
becomes %26. This tool encodes or decodes entirely in your browser; nothing
you type is ever sent to a server. We tested the malformed-input case directly: strings
like a stray % or %zz return a clear message here rather than
the blank or garbled output some tools produce.
Which characters get encoded?
| Character type | Examples | Encoded form |
|---|---|---|
| Unreserved (never encoded) | A–Z, a–z, 0–9, - _ . ~ | Passed through unchanged |
| Reserved (encoded when used as data) | : / ? # & = | %3A %2F %3F %23 %26 %3D |
| Space | %20 | |
| Non-ASCII characters | accented letters, CJK, emoji | Multi-byte UTF-8 sequences, e.g. %C3%A9 for é |
What's the difference between encodeURI and encodeURIComponent?
JavaScript's two built-in encoding functions have different scope, and mixing them up is
a common source of broken links. encodeURI() is meant for a complete,
already-structured URL: it leaves characters like : /
? & = alone since they're doing structural
work (separating the scheme, path, and query string). encodeURIComponent()
is meant for a single piece of data — a query parameter's value, say — and
encodes those same reserved characters too, since inside a component they're just data,
not structure. This tool encodes everything you give it as a component (the
encodeURIComponent behavior), which is what you want when you're building a
query string value piece by piece rather than encoding a URL that's already whole.
Why do I sometimes see + instead of %20 for spaces?
Both represent a space, but they come from two different encoding schemes with separate
histories. Percent-encoding (RFC 3986, what this tool uses) always writes a space as
%20. The older application/x-www-form-urlencoded scheme, used
when an HTML form submits data, encodes spaces as + instead — a
holdover from how early web forms worked. If you're decoding a query string from a
submitted form and see literal + characters, they typically mean spaces,
not literal plus signs.
Is there a length limit on what I can encode or decode?
Not from this tool specifically — since everything happens in your browser instead of on a server, your device's own memory is the real ceiling, not a number we've imposed. Very large inputs may take a moment longer to process, but there's no artificial cap on length.
Related tools
Need a different encoding? Use the Base64 Encode & Decode tool to convert text to and from Base64 instead.
Last reviewed: August 2026