URL Encoder & Decoder

What is a URL encoder and decoder?

URLs can only safely contain a limited set of characters — letters, digits, and a handful of punctuation. Percent-encoding is how everything else gets represented: spaces, accented letters, emoji, and punctuation being used the wrong way each turn into a % followed by two hex digits. Decoding reverses it back to the original characters.

This tool covers both directions across three different contexts, because "encode this for a URL" means different things depending on what you're encoding — a single value, an entire URL, or a field pulled from an HTML form. Picking the wrong one is the single most common cause of double-encoded or silently mangled URLs.

How to use it

1. Choose Encode or Decode. Click the Mode pill for the direction you need — encoding turns raw text into percent sequences, decoding turns them back.
2. Tell it what you're encoding. Under What are you encoding?, pick A single value, A whole URL, or A form field — this decides which characters get escaped and how spaces are handled, and getting it right matters more than the mode pill does.
3. Paste in, then copy the result. The output box updates as you type; press Copy (it becomes Copied! for two seconds) and check the counts row — Characters in versus Characters out — to see how much the encoding actually added.

Three modes, three different rules

A single value runs encodeURIComponent, which escapes everything except the RFC 3986 unreserved set — A–Z, a–z, 0–9, and - . _ ~. Notice what's missing from that exclusion list: ! ' ( ) and * survive untouched, because this function predates RFC 3986 tightening the unreserved set. A value containing an apostrophe or parentheses still looks encoded but can confuse a parser downstream that expects those characters to be escaped too.

A whole URL runs encodeURI instead, which leaves eleven more characters alone on top of those five: # $ & + , / : ; = ? and @ — the characters a URL needs to keep its structure intact. That's the entire difference between the two functions, and it's why you use encodeURI on a complete URL you don't want to break, and encodeURIComponent on a single value you're about to drop into a query string. Run a whole URL through encodeURIComponent and its own slashes and colons turn into %2F and %3A, and it stops working as a URL at all.

A form field exists because of the classic bug: HTML form submissions and URLSearchParams encode a space as +, not %20 — new URLSearchParams({q: "a b"}) produces q=a+b. But decodeURIComponent("a+b") returns the literal string "a+b", plus sign and all; it has no idea + is supposed to mean space there. Decode a form-encoded query string the naive way and every space silently becomes a literal plus in your data. Use the form-field mode on anything that came out of a form or a URLSearchParams object, and the other two modes everywhere else.

One detail worth knowing, since this tool delegates form encoding to URLSearchParams itself rather than reimplementing it: form mode is actually stricter than encodeURIComponent. It escapes four of those five stragglers — ! ' ( ) become %21 %27 %28 %29 — and leaves only * alone.

What this tool doesn't do

encodeURIComponent doesn't touch ! ' ( ) or * — they're left alone regardless of context, so encoded output can still contain characters a strict downstream parser rejects. Check what's actually consuming the string before assuming encoding alone makes it safe.

Decoding isn't forgiving of malformed input — a truncated percent sequence is a hard error, not a best-effort guess. decodeURIComponent("%E0%A4%A") throws a URIError rather than returning something close, so if your input might be cut off or corrupted, expect this tool to say so instead of silently patching it. Whole-URL decoding is deliberately the true inverse of encodeURI, which means %2F stays as %2F: turning it back into a slash would change the URL's shape rather than just its text.

Nothing is uploaded and nothing is stored — encoding and decoding happen in your browser, so pasting a token, a session id, or anyone else's data here doesn't send it anywhere, and it's gone the moment you reload the page.

Why is it free?

Percent-encoding is a handful of character-set lookups — there's no infrastructure behind it worth charging for. It runs the same as everything else on FreeToGenerate.com: computed in your browser, nothing to meter, no reason for a paywall.