How to Encode a URL: encodeURI vs encodeURIComponent, Explained With One Example

Every broken link you have ever pasted into a chat, and every search that silently returned the wrong results, probably comes down to one character that should have been encoded and was not — or one character that was encoded and should have been left alone. URLs can only safely carry a limited set of characters, so everything else has to be percent-encoded: a space becomes %20, an ampersand becomes %26, and a non-English letter becomes a run of triplets. The trouble is that JavaScript ships two encoders, and picking the wrong one breaks the link in opposite ways. Our free URL encoder and decoder converts in both directions live as you type, explains the difference between the two modes, flags malformed input in plain English, and includes a quick reference table of the characters you will meet most. This guide explains the one rule that decides which mode to use, works the example the tool itself uses, and lists the mistakes that even experienced developers keep making.

How to Use the Encoder

1. Pick a mode. Encoding one value for a query string — a search term, a name, a redirect target? Keep Component (encodeURIComponent), the default and the right choice about 90% of the time. Encoding an entire address that already has its https://, its slashes, and its query structure? Switch to Full URL (encodeURI), so the structure survives. 2. To encode, type or paste readable text into the Decoded box. The encoded form appears instantly on the right; there is no button to press, because both directions convert live. 3. To decode, paste percent-encoded text — full of %20s and %26s — into the Encoded box. Readable text appears on the left. 4. Compare modes with one click. Switching modes re-converts whatever is in the boxes, so you can watch the same input diverge under the two encoders and feel the difference instead of memorising it. 5. Copy or clear. Copy the encoded result with the button, or clear both boxes to start fresh. If your input is malformed — a lone %, a truncated triplet like %2, or non-hex digits after % — the tool produces a plain-English error instead of a silent wrong answer, and tells you which mode it failed under. That error is a feature, not an annoyance: a decoder that silently guesses at malformed input is how corrupted data travels further than it should.

encodeURI vs encodeURIComponent: The Difference That Matters

JavaScript ships two encoders because URLs have two jobs: structure and content. encodeURI assumes you are handing it a complete, working URL and encodes only what would break it — spaces, non-ASCII characters, and a few others — while deliberately leaving the structural characters alone: colon, slash, question mark, hash, brackets, at sign, exclamation, dollar, ampersand, apostrophe, parentheses, asterisk, plus, comma, semicolon, and equals. encodeURIComponent assumes you are handing it one piece of a URL and escapes everything that could be mistaken for structure, leaving only letters, digits, hyphen, underscore, dot, exclamation, tilde, asterisk, apostrophe, and parentheses untouched. The rule is mechanical, which is good news, because mechanical rules do not require judgement: if the string already contains URL syntax you want to keep, it is a URI, so use encodeURI. If it is data being placed into URL syntax, it is a component, so use encodeURIComponent. The classic bug is using the wrong one, and it fails in both directions. Encode a full URL with encodeURIComponent and your https:// becomes https%3A%2F%2F — a dead link. Encode a query value with encodeURI and a user's ampersand survives to split your query string in half, or a hash truncates everything after it into a fragment. Neither failure produces an error message. Both produce a link that looks fine and behaves wrong, which is why this distinction, dull as it sounds, is one of the most valuable things a working developer can internalise.

Worked Example: Fish and Chips

Take a search URL with a tricky query — a user typed "fish & chips?" — and watch the two modes diverge. Step one: the full URL, encoded with encodeURI, keeps its structure intact and escapes only the spaces, giving https://example.com/search?q=fish%20&%20chips? — the slashes, question mark and ampersand that hold the URL together are untouched. Step two: the same URL, encoded with encodeURIComponent, escapes everything, giving https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Dfish%20%26%20chips%3F — a string that is no longer a URL at all, just a pile of triplets. Step three: just the value, encoded with encodeURIComponent, gives fish%20%26%20chips%3F — safe to append after ?q=, because the ampersand that would have split the query is now inert. Step four: decode it back, and you get fish & chips? — an exact round trip, which is the test every encoding should pass. Step one versus step two is the whole lesson in one glance: the right encoder preserves meaning, and the wrong one preserves nothing. Try all three inputs in the tool and flip the mode radio to feel the difference, because this is one of those concepts that clicks the moment you see the same input under both modes, and stays fuzzy for as long as you only read about it. The same pattern governs every other encoding job on the site: our Base64 guide covers the other encoding developers reach for daily, our JSON formatting guide deals with the data those URLs usually carry, and our regex testing guide helps you validate the patterns before they ever reach a URL.

Characters You Will Meet Most

You do not need to memorise the reference table — the tool does the work — but recognising the frequent triplets makes debugging URLs dramatically faster. A space is %20. A plus sign is %2B. An exclamation mark is %21, a comma %2C, a hash %23, a slash %2F, a dollar %24, a colon %3A, an ampersand %26, a semicolon %3B, an apostrophe %27, an equals sign %3D, an opening parenthesis %28, a question mark %3F, a closing parenthesis %29, an at sign %40, an asterisk %2A, an opening bracket %5B, and a closing bracket %5D. The interesting case is non-ASCII text: the letter é becomes %C3%A9, because non-ASCII characters are first encoded as UTF-8 bytes, and then each byte is percent-encoded. One character can become two, three, or four triplets, which is why encoded URLs with international text look so long — they are not bloated, they are just spelling out bytes. When you see a long run of %C3 or %E2 triplets in a URL, you are looking at ordinary text in its transport form, and decoding it restores the original characters exactly. Recognising %20, %26 and %3F on sight covers most debugging: spaces in a path, an ampersand inside a value, and a question mark that belongs to the query rather than the data.

Common Mistakes

Encoding a full URL with encodeURIComponent. The single most common encoding bug, and the one that produces the dead https%3A%2F%2F link. If the string already works as a URL, it is a URI: use encodeURI. Encoding a query value with encodeURI. The mirror-image bug. A user's & survives to split your query string in half, or a # truncates everything after it into a fragment, and the server receives half the data you sent. Double-encoding. Encoding twice turns %20 into %2520, and nothing complains — the URL just quietly stops meaning what you intended, and the decoded value comes back as the literal text "%20" instead of a space. If your output contains %25, you have almost certainly encoded something that was already encoded. Decoding a component with the full-URL decoder. decodeURI deliberately leaves encoded reserved characters like %23 (the hash) alone, so decoding a component with the full-URL decoder gives a half-decoded result that looks like a bug in the data. Treating + as a space in a path. A plus means space only in form data: HTML forms submit spaces as +, but in a URL path a plus is a literal plus sign. Decoding a path with form rules, or vice versa, corrupts data; this tool treats + literally, which is correct for URLs. Thinking encoding is validation or security. An encoded URL can still be a phishing link, and encoding user input does not make it safe for HTML or SQL — those are different escaping jobs with different rules, and conflating them is how injection bugs happen.

Limits Worth Knowing

Percent-encoding is a transport trick with sharp edges, and knowing where it stops is part of using it well. It does not validate anything: a perfectly encoded URL can point somewhere malicious, and a malformed one can still be a valid address once fixed, so encoding is never a substitute for checking where a link goes. It does not protect against injection: HTML escaping, SQL parameterisation, and URL encoding are separate layers, and applying the wrong one leaves the real hole open. It is not compression: international text expands to two to four triplets per character, so heavily non-ASCII URLs get long, and length limits on some systems can bite. Decoding is not always reversible in the naive sense: a decoder that leaves reserved characters encoded, or a form decoder that turns plus signs into spaces, can return something different from the original, which is why the tool reports malformed input in plain English instead of guessing. And encoding does not survive every copy-paste: chat apps, email clients, and documents sometimes decode or re-encode URLs on their own, so a link that worked in your editor can break in transit for reasons that have nothing to do with your code. With those limits in mind, the encoder does its job cleanly: it converts live, it distinguishes structure from content, it explains its failures, and it lets you compare both modes on the same input with one click. That is everything a URL encoder needs to do, and it is why the one rule — whole URL, encodeURI; one value, encodeURIComponent — is worth committing to memory, because it is the rule you will use a hundred times a year without ever thinking about it again.

Frequently Asked Questions

More guides from ToolNest