URL encode & decode

Component vs full URL

When you put text into a URL — a search term, a parameter value — characters like spaces, ampersands and question marks have to be percent-encoded so they aren't mistaken for URL structure. Use component mode (encodeURIComponent) for a single value like a query parameter, which escapes &, =, ? and /. Use full URL mode (encodeURI) when you want to encode a whole address while leaving its structural characters intact.

Why encoding matters

A URL has a grammar, and certain characters are part of it: ? starts the query string, & separates parameters, / separates path segments, # starts a fragment. If those characters appear inside a value — a search term, an email address, a redirect target — they must be percent-encoded so the browser doesn't read them as structure. That's why a space becomes %20 and an ampersand becomes %26.

Which mode, in practice

Use component encoding for a single piece you're dropping into a URL, such as one parameter value, and full-URL encoding when you want to keep the overall structure intact and only escape the illegal bits. For query values, component encoding is the safe default.

What actually gets encoded

Percent-encoding replaces a character with % followed by its byte value in hexadecimal. A space becomes %20, an ampersand %26, a question mark %3F and a forward slash %2F. Non-ASCII text is encoded as UTF-8 bytes first, so café becomes caf%C3%A9 and an emoji expands to four bytes: 😀 is %F0%9F%98%80.

The percent sign itself must be encoded as %25, which is why double-encoding produces the classic mangled result — encode a b twice and you get a%2520b, because the % of %20 was itself escaped on the second pass.

The space problem: %20 versus +

There are two encodings in circulation and they disagree about one character. encodeURIComponent follows RFC 3986 and turns a space into %20. HTML form submission uses application/x-www-form-urlencoded, an older scheme that turns a space into + — and consequently has to encode a literal plus as %2B.

Both appear in real query strings, and most server frameworks accept either in the query component. The failure case is treating a literal + as a space: if a value can legitimately contain a plus — a phone number, a formula, a base64 string — it must be encoded as %2B or it will decode wrongly. Note this rule applies to the query string; a + in a path segment stays a plus.

Choosing the right mode

• Component mode is what you almost always want. Use it on each individual value you are inserting — a search term, a parameter, a path segment — because it escapes the structural characters &, =, ? and / that would otherwise be read as URL grammar.
• Full URL mode deliberately leaves that grammar intact, so it is only for tidying an entire address that is already assembled correctly. Running it on a single value is the standard bug: a search term containing & passes straight through and silently splits into two parameters.

A useful check on any decoded result: if you see % followed by something that is not two hex digits, the string was not valid percent-encoding to begin with — a stray literal % in the input is the usual cause. For encoding binary data rather than URL text, the Base64 tool is the right one.