Web Fundamentals
Why %20, %26, and encodeURIComponent matter — and when to use each.
If you have ever built a URL by hand and watched it break the moment a user typed an ampersand or a space, you have met the problem that URL encoding solves. This guide explains percent-encoding from the ground up: what it is, why it exists, the famous %20-versus-+ confusion, and how to encode correctly in JavaScript and other languages. You can follow along with the free URL Encode / Decode tool.
What URL Encoding Actually Does
A URL can only safely contain a limited set of ASCII characters. Some characters — like ?, &, =, #, and / — are reserved because they define the structure of the URL itself. Others, like spaces and non-ASCII letters, simply aren't allowed in a raw URL. Percent-encoding (defined in RFC 3986) solves both problems by replacing a character with a % followed by its two-digit hexadecimal byte value. A space becomes %20, an ampersand becomes %26, and so on.
The reason this matters is meaning. https://shop.test/search?q=Tom & Jerry is ambiguous — the unencoded & looks like the start of a second parameter. Encoded as q=Tom%20%26%20Jerry, the value is unmistakably a single string containing an ampersand. Encoding preserves your data's meaning as it travels through URLs.
The %20 vs + Confusion
This trips up nearly everyone. There are two ways a space can appear in a URL:
%20— the universal percent-encoding. Valid anywhere in a URL: path, query, or fragment.+— means a space only insideapplication/x-www-form-urlencodeddata, which is what HTML forms submit and how many query strings are built.
In a path segment, a + is a literal plus sign, not a space. In a query string, both are accepted by most servers. The safe default is %20 — it works in every context. We cover this in depth on the encoding spaces guide.
encodeURI vs encodeURIComponent
JavaScript gives you two functions, and picking the wrong one is the single most common URL bug:
encodeURIComponent()encodes a single value — a query parameter or path piece. It encodes the structural characters&,=,?, and#so your value can't corrupt the URL. Use this most of the time.encodeURI()encodes a whole URL and deliberately preserves those structural characters so the URL still works. Use it only on an already-assembled URL.
The classic mistake is using encodeURI() on a parameter value, which leaves & and = intact and breaks the query string. There is a dedicated encodeURI vs encodeURIComponent comparison if you want the full breakdown.
Encoding in JavaScript the Right Way
For a single value, reach for encodeURIComponent(). For building a whole query string, the URLSearchParams API is cleaner because it encodes every key and value automatically:
encodeURIComponent('Tom & Jerry')→Tom%20%26%20Jerrynew URLSearchParams({ q: 'Tom & Jerry', page: 2 }).toString()→q=Tom+%26+Jerry&page=2- Decode with
decodeURIComponent().
See the full URL encoding in JavaScript guide for more patterns, and the query string encoding guide for building parameters safely.
Special Characters and Unicode
Every reserved character has a fixed code: & → %26, = → %3D, ? → %3F, # → %23, / → %2F, @ → %40. Non-ASCII characters and emoji are first converted to UTF-8 bytes, then each byte is percent-encoded — so café becomes caf%C3%A9. Always use UTF-8; legacy encodings will corrupt accented and non-Latin text. The special characters guide lists the common ones, and the reference table on the main tool page covers the rest.
Encoding vs Encryption vs Hashing
One last clarification: URL encoding is not security. It is a reversible representation, just like Base64 — anyone can decode it. If you need to hide data, encrypt it; if you need to verify integrity, hash it. Encoding exists purely to make data safe to transmit, not secret. Confusing the two is a common and dangerous mistake.
Try It Yourself
The fastest way to build intuition is to paste a few strings into the URL encoder/decoder and watch what changes. Everything runs in your browser — nothing is sent to a server — so it is safe to test with real values.