Percent-Encoding Explained

URL encoding — also called percent-encoding — is how text is made safe to travel inside a web address: every character a URL cannot carry is replaced by a % sign followed by two hexadecimal digits, so a space becomes %20 and é becomes %C3%A9. It looks simple, yet the details break real links every day: a + that should have been %2B, a value encoded twice into %2520, an & that silently splits a query in two.

What is URL encoding (percent-encoding)?

A URL can only contain a limited set of ASCII characters, because certain characters are reserved as structure: / ? & = # separate its parts. RFC 3986 sorts characters into classes, with one rule for anything outside them: write the byte as % plus its two-digit hexadecimal value — the % sign itself becomes %25:

The practical reading: reserved characters need encoding only when they are data rather than structure — an & inside a search term must become %26, while the & separating two parameters must not. Get the small details right, too — a colon encodes to %3A; some reference tables online wrongly print %3D, which is actually the code for =.

Why is a space %20 in a path but + in a form?

Because two different rules meet in the query string. Everywhere in a URL, a space's percent-encoded form is %20. But HTML forms submit data as application/x-www-form-urlencoded, an older format in which a space is written as +. Servers parsing form submissions — and most query strings along with them — read + as a space.

In a path, no such rule exists: + is an ordinary allowed character, a literal plus sign. /files/hello+world.txt names a file literally called hello+world.txt; /files/hello%20world.txt names hello world.txt. The mirror trap: a real plus sent as data must be %2B — an unencoded C++ in a form search reads back as “C” plus two spaces.

This is also why decoding surprises people: JavaScript's decodeURIComponent never converts + to a space, in any context. Correct form decoding replaces + with a space first, then percent-decodes — the order matters, or a genuine %2B would be corrupted. One more distinction: form encoding also escapes ~ ! ' ( ), leaving only A–Z a–z 0–9 and * - . _ untouched.

What is the difference between encodeURI and encodeURIComponent?

JavaScript ships two encoders because URLs hold two kinds of content: the structure, and the values inside it. encodeURI is for a complete, already-formed URL — it preserves the structural characters. encodeURIComponent is for one value you are inserting — it encodes those same characters so they cannot be mistaken for structure:

MDN's canonical bug shows the cost of choosing wrong: encodeURI("https://example.com/?choice=Ben & Jerry's") leaves the & untouched, so the server reads two parameters. Note also what neither function does: both leave ! ' ( ) * unescaped even though RFC 3986 reserves them — so neither output is strict RFC 3986, and neither produces form encoding. Decoding mirrors the split: decodeURI will not decode escapes for the structural characters; decodeURIComponent decodes all.

How is non-English text encoded in a URL?

In two steps: the text is first written as UTF-8 bytes, then every byte that is not an unreserved ASCII character becomes a %XX triplet. One character can therefore produce several triplets:

• é (U+00E9) is two UTF-8 bytes, C3 A9 → %C3%A9 — so café becomes caf%C3%A9.
• اردو (Urdu for “Urdu”) is four Arabic letters, two bytes each → %D8%A7%D8%B1%D8%AF%D9%88.
• 😀 (U+1F600) is four bytes, F0 9F 98 80 → %F0%9F%98%80.

The pattern: one byte for ASCII, two for most European and Middle-Eastern scripts, three for CJK, four for emoji. One exception — international domain names use Punycode instead; percent-encoding applies to the path, query and fragment.

What is double encoding — and how do you fix %2520?

Encode an already-encoded string and the % signs themselves get encoded: % becomes %25, so %20 turns into %2520 and hello world becomes hello%2520world. The server decodes once, gets %20 back, and stores the still-encoded text — links break, searches miss, tokens fail.

It usually happens in layers — a framework auto-encodes a value you already encoded, or a redirect chain encodes the redirect= parameter again at every hop. Detection is a strong hint, not proof: %25 followed by two hex digits suggests double encoding, but the literal text “%20” legitimately encodes to %2520, so a careful tool flags it and offers to decode one more level rather than silently “fixing” it. Prevention is simpler: keep values raw and encode exactly once, at the boundary.

Why does decoding fail with an error?

Strict decoders such as decodeURIComponent throw a URIError — rightly, because some inputs have no correct decoding:

• A % not followed by two hex digits — %ZZ, a truncated %2, or a trailing % at the end of the string.
• Escapes that do not form valid UTF-8 — %C3 on its own (half of é), %C3%28, or %FF, a byte that can never appear in UTF-8. There is no character these decode to — anything a tool prints anyway is a guess.
• A lone surrogate — half of an emoji pair left over from sloppy string slicing — makes the encoders throw, too.

Your browser's address bar is more forgiving — it passes a bad % through literally and swaps invalid bytes for � — which is why broken URLs can seem to “work” in the browser yet fail in code. When a decoder rejects input, a useful report names the position and the offending sequence; silent no-ops and boxes that just turn red tell you nothing. ToolsOfWeb's URL encoder and decoder pinpoints the bad sequence and its position instead.

Is it safe to paste URLs into an online encoder?

Look at what flows through URLs: API keys in query strings, session tokens, password-reset links, signed download URLs, OAuth callbacks. Percent-encoding is arithmetic your browser does natively in microseconds — yet several popular encoder sites send whatever you paste to their server to do it.

A browser-local tool removes the question entirely — and the claim is verifiable: open your Network tab while converting and you will see zero requests leave the page. Every ToolsOfWeb utility works this way — the Base64 converter and the JWT decoder — URLs and tokens are exactly the kind of data that should never leave the tab. Encode and decode your next URL with the free URL encoder and decoder.

FAQs

For more free utilities, see ToolsOfWeb's Base64 Encoder & Decoder guide and JWT Decoder guide.