URL Encoder & Decoder

Encode full URLs or URL components — or decode percent-encoding back to readable text — instantly, live as you type. This free URL encoder and decoder explains the difference between encodeURI and encodeURIComponent, flags malformed input in plain English, and includes a quick reference table of the characters you will meet most.

How to Use the URL Encoder & Decoder

Both directions convert live — type on either side and the other updates:

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 90% of the time. Encoding an entire address that already has its https://, slashes, and 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.
3. To decode: paste percent-encoded text (full of %20s and %26s) into the Encoded box. Readable text appears on the left.
4. Switching modes re-converts whatever is in the boxes, so you can compare encodeURI and encodeURIComponent output on the same input with one click.
5. Copy the encoded result with the button, or Clear both boxes to start fresh.

Malformed input — a lone %, a truncated triplet like %2, or non-hex digits after % — produces a plain-English error instead of a silent wrong answer, and tells you which mode it failed under.

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. encodeURIComponent assumes you are handing it one piece of a URL and escapes everything that could be mistaken for structure, leaving only A–Z a–z 0–9 - _ . ! ~ * ' ( ) untouched.

The classic bug is using the wrong one. 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 & survives to split your query string in half, or a # truncates everything after it into a fragment. The rule is mechanical: if the string already contains URL syntax you want to keep, it is a URI — use encodeURI. If it is data being placed into URL syntax, it is a component — use encodeURIComponent.

Worked Example

Take a search URL with a tricky query — a user typed fish & chips? — and watch the two modes diverge:

Step 1 versus step 2 is the whole lesson in one glance: the right encoder preserves meaning, the wrong one preserves nothing. Try all three inputs in the tool above and flip the mode radio to feel the difference.

Common Encoded Characters Reference

You do not need to memorize these — the tool does the work — but recognizing the frequent ones makes debugging URLs dramatically faster:

Note é → %C3%A9: non-ASCII characters are first encoded as UTF-8 bytes, 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.

Limitations

Percent-encoding is a transport trick with sharp edges. + means space only in form data — HTML forms submit spaces as +, but in a URL path + 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. Double-encoding is silent: encoding twice turns %20 into %2520, and nothing complains — the URL just quietly stops meaning what you intended. decodeURI will not decode everything: it deliberately leaves encoded reserved characters like %23 (#) alone, so decoding a component with the full-URL decoder gives a half-decoded result. Encoding is not validation: an encoded URL can still be a phishing link, and encoding user input does not make it safe for HTML or SQL — those need their own escaping. And length limits still apply: browsers and servers cap URL length (around 2,000 characters in practice for Internet Explorer-era compatibility, ~8KB on many servers), so a heavily encoded long value can push a GET request over the edge — that is what POST bodies are for.

Guides for This Tool

Frequently Asked Questions

Related Tools