URL Encoder & Decoder

What percent-encoding is

A URL may only contain a limited set of ASCII characters. Any character outside that safe set — spaces, accented letters, punctuation, or Unicode — must be percent-encoded: replaced by a % followed by two hexadecimal digits representing the byte value. A space becomes %20, a hash (#) becomes %23, and so on.

This is not compression or encryption — it is a reversible transformation defined by RFC 3986 that makes any string safe to transmit as part of a URL. It's also unrelated to Base64, another common web-safe encoding — Base64 turns arbitrary binary data (like an image) into text; percent-encoding turns unsafe characters within a URL into a safe form.

encodeURIComponent vs encodeURI

JavaScript provides two encoding functions and the difference matters:

• encodeURI encodes a complete URL. It leaves characters that have structural meaning in a URL untouched — /, ?, #, &, =, : — because removing them would break the URL structure.
• encodeURIComponent encodes a component — a single query value, a path segment, or a fragment. It encodes those same structural characters, because inside a component they are data, not structure.

This tool uses encodeURIComponent, which is almost always what you want. If you are encoding the value of a query parameter — for example the search term in ?q=hello world — you need the component version so the space becomes %20 and does not accidentally split the URL.

Unicode handling

Modern URLs (IRIs) can contain Unicode characters, but the underlying encoding is still bytes. encodeURIComponent converts each Unicode character to its UTF-8 byte sequence first and then percent-encodes each byte. An em dash (U+2014, UTF-8: E2 80 94) becomes %E2%80%94. Decoding reverses the process exactly, so the round-trip is lossless for any valid Unicode text.

Worked example

Encoding hello world produces:

hello%20world

Decoding that result returns hello world exactly.

Worked example — encoding a full URL as a component

A whole URL used as a query value must be encoded as a component, not as a URL, otherwise its own ? and & would be read as part of the outer URL. Encoding https://example.com/search?q=foo bar&lang=en produces:

https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dfoo%20bar%26lang%3Den

Every character with structural meaning — :, /, ?, =, &, the space — is escaped, so the whole string can be appended safely after another URL's own ? without breaking it.

When decoding fails

Not every string containing % is valid percent-encoding. A sequence like %ZZ is malformed — ZZ is not a valid hexadecimal pair. This tool catches that error and shows a clear message rather than returning garbled text.

Edge cases and limitations

• Double-encoding. Running already-encoded text through the encoder again encodes the % itself, turning %20 into %2520. If a decoded result still contains percent signs followed by two hex digits, the original text was probably encoded more than once.
• Decoding doesn't turn + into a space. decodeURIComponent treats + as a literal plus sign. Data from an HTML form (application/x-www-form-urlencoded) does use + for spaces, so decoding a raw form-encoded query string here leaves the pluses in place rather than turning them into spaces — replace + with a space first, or only use this tool on genuine RFC 3986 percent-encoded text.
• A handful of characters are never encoded. encodeURIComponent leaves A–Z, a–z, 0–9, and - _ . ! ~ * ' ( ) untouched. Most are harmless in a URL component, but a few strict validators reject !, *, ', ( or ) unescaped — rare in practice, but worth knowing if a downstream system complains about an otherwise correctly encoded string.

Frequently asked

When do I need to encode a URL?

Any time you construct a URL programmatically — building a query string, setting a redirect target, creating a share link — you should encode each value separately with encodeURIComponent before joining the parts together.

Why does a space sometimes appear as + in URLs?

The application/x-www-form-urlencoded format (used by HTML forms) encodes spaces as +. RFC 3986 percent-encoding encodes them as %20. This tool follows RFC 3986, which is correct for modern URLs.

Is my input sent anywhere?

No. Encoding and decoding run entirely in your browser. Nothing you type is transmitted.

Why does my URL have %2520 in it instead of %20?

That's double-encoding: the value was encoded once, then encoded again somewhere else in the pipeline — a form submission followed by a redirect is a common cause. Decode it twice to recover the original: once to get back to %20, and again to get back to a space.

Is percent-encoding the same as Base64?

No. They solve different problems: percent-encoding escapes specific unsafe characters within a URL, while Base64 re-encodes entire binary data as text. A percent-encoded string still contains the original readable characters wherever they were already URL-safe; a Base64 string doesn't.