URL Encode / Decode

Percent-encoding lets characters with structural meaning in a URL travel as data. Two JavaScript functions do it, they escape different character sets, and choosing the wrong one produces either a broken URL or a security hole. This shows both directions at once.

How to use it

1. Paste a raw value or an encoded one into the input.
2. Both encodeURIComponent and decodeURIComponent results are shown together.
3. Copy the one you need. Nothing is transmitted.

encodeURI versus encodeURIComponent

The difference is what each one considers structural.

encodeURI assumes you are handing it a complete URL and preserves the characters that give a URL its shape: the colon, slashes, question mark, ampersand, equals sign, hash, and a few others. It is for taking an entire URL that contains spaces or accented characters and making it transmittable.

encodeURIComponent assumes you are handing it one piece that must be inserted into a URL, and escapes everything that is not unreserved. Slashes, ampersands, equals signs, and question marks all become percent sequences, because inside a query parameter value those characters would otherwise change the structure of the URL.

Almost every practical case is the second one. If you are building a query string, encodeURIComponent is correct for each key and each value. Using encodeURI there is a genuine bug: an ampersand in a user-supplied value survives unescaped and injects an extra parameter, which is a parameter-pollution vulnerability.

The characters that stay unescaped

encodeURIComponent leaves alone the ASCII letters, the digits, and hyphen, underscore, dot, exclamation mark, tilde, asterisk, single quote, and parentheses.

The last six are a historical artefact. RFC 3986 classifies exclamation mark, asterisk, single quote, and parentheses as sub-delimiters rather than unreserved characters, and some servers treat them as structural. Wikipedia URLs containing parentheses are the well-known case where this causes trouble. If you are generating URLs consumed by a strict parser, escape those four manually.

Plus signs, spaces, and the encoding nobody agrees on

A space in a URL can legitimately appear as %20 or as a plus sign, and which one is correct depends on where in the URL it sits.

Percent-encoding proper, as defined for URIs, always uses %20. The plus convention comes from HTML form submission, which uses application/x-www-form-urlencoded, a related but distinct format where plus means space and a literal plus must be written %2B.

The practical consequence is that a query string built with encodeURIComponent uses %20, while one produced by a submitted HTML form uses plus, and a server that decodes with the wrong rule turns every plus in your data into a space. Email addresses with a plus tag are where this shows up: user+tag@example.com arrives as user tag@example.com.

URLSearchParams in the browser follows the form-encoding convention and produces plus signs, which frequently surprises people who expected it to match encodeURIComponent.

Double encoding

Encoding a value twice turns the percent sign of the first pass into %25, so %20 becomes %2520. The result decodes once to %20 rather than to a space, and the value arrives with visible percent sequences in it.

This happens whenever a value passes through two layers that each helpfully encode, which is common when a framework encodes a route parameter that the calling code had already encoded. The symptom is unmistakable once you know it: look for %25 in a URL that should not contain a literal percent sign.

The opposite failure, decoding twice, is a security problem rather than a cosmetic one. A path filter that rejects ../ can be bypassed with %252e%252e%252f if something downstream decodes a second time. Decode exactly once, and validate after decoding rather than before.

At a glance

Frequently asked questions

Read more

Formatting and encoding — Pretty-printing catches bugs, Base64 costs 33 percent, and escaping applied in the wrong context prevents nothing.

Related tools