URL Encoding Explained: What Percent-Encoding Actually Does (and When You Need It)

If you've ever seen a URL with %20 where a space should be, or noticed a plus sign turn up in a search query, you've already encountered URL encoding without necessarily knowing its name. It's one of those web fundamentals almost everyone runs into eventually — building a share link, debugging a broken query parameter, handling a filename with a space in it — but rarely gets explained properly. This guide covers what URL encoding actually is, why it exists, exactly which characters need it, the difference between the two encoding functions JavaScript gives you, and the mistakes that quietly break links, redirects and form submissions.

What URL encoding actually is

A URL can only safely contain a limited set of characters: letters, digits, and a small handful of punctuation marks like - . _ ~. Everything else — spaces, ampersands used as literal text, accented letters, emoji, characters like < > " { } | \ ^ — either has no defined meaning inside a URL or is already reserved for a different purpose (an & separates query parameters, a ? starts the query string, a # starts a fragment). URL encoding, formally called percent-encoding, is the mechanism that lets you represent any of those characters safely: it converts the character's byte value into a % followed by two hexadecimal digits. A space becomes %20. An ampersand meant as literal text becomes %26. A rupee sign (₹) becomes %E2%82%B9 — three encoded bytes, because it's represented in UTF-8 as three bytes, and each one gets its own percent-encoded pair.

Why the web needs this at all

URLs are parsed by splitting on specific reserved characters — a colon and double slash mark the scheme, a question mark starts the query string, an ampersand separates one query parameter from the next, an equals sign separates a parameter's name from its value, a hash starts the fragment. If your actual data contains one of those characters — say, a search query for "cats & dogs" — and you insert it into a URL without encoding it, the parser has no way to tell your literal ampersand apart from a genuine parameter separator. The link silently breaks into pieces it was never meant to be split into. Percent-encoding sidesteps the whole problem: it converts your literal ampersand into %26, which the URL parser will never mistake for a separator, and the receiving server decodes it back into an ampersand before your application ever sees the value.

Reserved characters vs unreserved characters

The relevant standard (RFC 3986) splits characters into two groups. Unreserved characters — uppercase and lowercase letters, digits 0–9, and - _ . ~ — are always safe to use literally anywhere in a URL and never need encoding. Reserved characters — things like : / ? # [ ] @ ! $ & ' ( ) * + , ; = — have a defined structural meaning in certain positions of a URL (a / separates path segments, a ? starts the query, an & separates parameters) but can appear as literal data elsewhere, which is exactly what makes them tricky: whether a given reserved character needs encoding depends entirely on where in the URL it sits and what it represents there, not on the character alone.

encodeURIComponent vs encodeURI — the mistake almost everyone makes at least once

JavaScript ships two different encoding functions, and mixing them up is probably the single most common URL-encoding bug developers hit. encodeURIComponent() is the aggressive one: it encodes nearly everything except unreserved characters, including reserved characters like & ? # / = — which makes it the correct choice whenever you're encoding a single piece of data that will be inserted into a URL, such as a query parameter value, a path segment, or a value going into a form field. encodeURI() is the gentler one: it's designed for encoding an entire URL that may already contain structural reserved characters you want left alone — it leaves : / ? # & = untouched because those are assumed to already be doing their structural job. Using encodeURI() on a single value is the classic mistake: if that value happens to contain an & or a #, encodeURI() won't touch it, and it'll silently get interpreted as a URL structural character instead of your literal data — which is exactly the bug percent-encoding was supposed to prevent in the first place.

Common characters and what they actually encode to

• Space → %20 in a URL path or standard percent-encoding, but historically becomes a literal + inside an application/x-www-form-urlencoded body (classic HTML form submissions and query strings) — both are "correct" depending on context, which is a frequent source of confusion.
• & (ampersand) → %26 — essential whenever an ampersand is part of your actual data rather than a query-parameter separator, e.g. a search for "rock & roll."
• = (equals sign) → %3D — needed if an equals sign is part of a value rather than the name=value separator.
• ? (question mark) → %3F — needed if a literal question mark appears anywhere after the URL's own query string has already started.
• # (hash) → %23 — needed for a literal hash in data, since an unencoded # is read as the start of a URL fragment and everything after it is silently dropped from what gets sent to the server.
• / (forward slash) → %2F — needed when a slash is part of a value rather than a path separator, such as a date like 15/08/2026 embedded in a query parameter.
• + (plus sign) → %2B — needed for a literal plus in data, since a raw + inside a query string or form body is itself interpreted as an encoded space in that context.

Where URL encoding actually shows up in real work

It's easy to think of this as a niche technical detail, but it surfaces constantly in ordinary tasks. Building a "share on WhatsApp" or "share on Twitter" link means encoding the message text as a query parameter, since the message will almost certainly contain spaces and often punctuation that needs escaping. Passing a redirect URL as a parameter to another page — a common login flow pattern like ?redirect=/dashboard?tab=billing — requires encoding the inner URL's own ? and = so the outer URL's parser doesn't misread them as its own parameters. Filenames with spaces or special characters, when referenced in a URL rather than a local file path, need the same treatment. And search boxes that build a URL from whatever the user typed need to encode that input before it's appended, since users routinely type ampersands, hashes and other reserved characters in ordinary search terms without thinking about it.

Common mistakes that quietly break things

• Encoding the same string twice — running an already-encoded %20 through an encoder again turns it into %2520 (the % itself gets encoded to %25), which then fails to decode back to the original value correctly. This tends to happen when encoding logic exists in more than one layer of an application and neither layer knows the other already did it.
• Using encodeURI() on a single form value instead of encodeURIComponent(), silently leaving & = # unencoded inside data that then gets misread as URL structure rather than literal content.
• Forgetting to encode a redirect target before appending it as a query parameter, which breaks as soon as the inner URL contains its own ? or & — a common cause of login-redirect bugs that only appear for certain destination pages.
• Manually building URLs with string concatenation and simply forgetting to encode a value at all, which usually works fine in testing with simple alphanumeric data and only breaks once a real user enters a space, an apostrophe, or an emoji.
• Assuming a space always encodes to %20 — it does in the URL path and in standard percent-encoding contexts, but form submissions using the application/x-www-form-urlencoded content type traditionally encode a space as + instead, and mixing up which context you're in produces subtly wrong output.
• Not decoding a value on the receiving end — encoding without a matching decode step just moves the problem instead of solving it; the recipient needs to run the corresponding decode function to get the original data back.

How to encode or decode a URL without writing code

For a one-off — debugging why a link isn't working, checking what a mysterious %E2%82%B9 actually decodes to, or preparing a value to paste into a URL by hand — you don't need to open a console and call encodeURIComponent() yourself. Our free URL Encoder does both directions in the browser: paste in plain text to see its percent-encoded form, or paste in an encoded string to see what it actually decodes to. It's useful for exactly the kind of debugging this guide covers — pasting a broken-looking URL in to see which character is the culprit, or checking that a redirect parameter you're about to hard-code is encoded correctly before it ships.

A quick way to reason about it without memorising the table

You don't need to memorise every character's hex code. The practical mental model is: if a character isn't a letter, a digit, or one of - _ . ~, and it's going into a URL as data rather than as structure, it should be percent-encoded — and in almost all modern code, calling encodeURIComponent() on that one piece of data handles it correctly without you needing to think about which specific characters are reserved. The cases worth remembering by name are the ones that cause the strangest, hardest-to-diagnose bugs when missed: an unencoded # silently truncates everything after it, an unencoded & silently splits one parameter into two, and an unencoded space breaks the URL outright in most contexts rather than just misparsing part of it.