URL Encoder & Decoder

How this works

URL encoding - percent-encoding - replaces characters that are unsafe or reserved in a URL with a percent sign and their byte value in hexadecimal. A space becomes %20, an ampersand becomes %26, a question mark becomes %3F. ⚠️ THIS TOOL ENCODES THE COMPONENT-SAFE WAY. In JavaScript terms it is encodeURIComponent, not encodeURI, and that is a deliberate choice rather than an omission. The two differ in how they treat the STRUCTURAL characters - : / ? # [ ] @ & = + $ and comma. A whole-URL encoder leaves them alone, because a complete address needs its slashes and its question mark to function. A component encoder escapes them too, because a single value being placed INTO a URL must not be able to punctuate the URL it is going into. Getting that backwards is the commonest URL bug there is. Encode 'salt & pepper' with a whole-URL encoder and the ampersand survives, so the server reads a search for 'salt ' plus a mystery parameter called ' pepper'. Encoded component-safe it becomes salt%20%26%20pepper and arrives intact. Since most encoding happens to VALUES rather than to whole addresses, the component encoder is the right default by a wide margin - so it is the only one here. If you need to encode a whole URL, encode each piece separately and assemble them; do not run a finished address through this. ⚠️ ENCODING WHAT YOU PASTED IS NOT ALWAYS WHAT YOU WANT. The plain encode row escapes your input exactly as given - so if you paste something already encoded, its percent signs get escaped again and you get %25 everywhere. That is the tool being literal rather than clever, and it is the same shape as accidental double-encoding, shown deliberately. The 'decoded, then encoded' row is the one to use in practice: it decodes first, so it produces the correct component form whether your input arrived raw or encoded. DECODING IS TOTAL AND NEVER THROWS. A malformed escape - a lone percent sign, or %ZZ - returns an EMPTY STRING rather than an error, because an exception inside a page breaks the page instead of reporting the problem. So an empty decoded output is the tool telling you the input is not valid percent-encoding, which is usually the answer you wanted. A PLUS SIGN IS NOT A SPACE HERE. In HTML form submissions a space is historically encoded as +, but that is a form-encoding convention rather than part of URL percent-encoding. A + in your input stays a +. If you are decoding something that came out of a form, replace the plus signs with spaces first - it is a genuinely separate step. NON-ASCII CHARACTERS BECOME MULTIPLE BYTES. Percent-encoding operates on bytes and modern URLs use UTF-8, so é becomes %C3%A9 - two escapes for one character. That is correct rather than a bug, and it is why an encoded string can be far longer than it looks.

Common questions

What is URL encoding for?

URLs have a limited alphabet and a set of characters that carry structural meaning - the slash separates path segments, the question mark starts the query, the ampersand separates parameters. Percent-encoding replaces anything unsafe or reserved with a percent sign followed by its byte value in hexadecimal, so a space becomes %20 and an ampersand becomes %26. It is what lets arbitrary text travel inside a structure that cares about punctuation.

Which kind of encoding is this?

Component-safe - encodeURIComponent, not encodeURI. The difference is the structural characters: a whole-URL encoder leaves : / ? # & = alone because a complete address needs them, while a component encoder escapes them too because a single value must not be able to punctuate the URL it is being placed into. Most encoding happens to values rather than whole addresses, so the component version is the right default by a wide margin. It is the only one here.

What if I need to encode a whole URL?

Encode each piece separately and assemble them - do not run a finished address through this tool, because it will escape the slashes and question mark that make the address work. That is not a limitation so much as the correct workflow: build the URL from parts you have each encoded, rather than encoding a structure after the fact. The 'decoded, then encoded' output is useful here, since it gives you the clean component form of a value whether or not it arrived encoded.

Why does 'salt & pepper' break a search?

Because the ampersand is what separates one query parameter from the next. If it survives into the URL unescaped, the server splits your value at that point - so a search for 'salt & pepper' arrives as a search for 'salt ' plus an unrelated parameter called ' pepper'. Component encoding turns it into %26 and the whole string arrives as one value. This single confusion accounts for a large share of all URL bugs.

My decoded output is empty.

Then the input is not valid percent-encoding. A lone percent sign, or an escape like %ZZ that is not valid hexadecimal, cannot be decoded - and the decoder deliberately returns an empty string rather than throwing, because an exception inside a page breaks the page rather than reporting the problem. An empty decode is the tool telling you the input is malformed.

Why didn't my + become a space?

Because a plus sign is not a space in percent-encoding. The plus-for-space convention comes from HTML form submissions, which use a related but different encoding, and it is not part of URL percent-encoding proper. A + stays a +. If you are decoding something that came out of a form, replace the plus signs with spaces before decoding - a genuinely separate step that catches people regularly.

Why did one accented letter become two escapes?

Because percent-encoding works on BYTES rather than characters, and modern URLs use UTF-8 where non-ASCII characters occupy more than one byte. So é becomes %C3%A9 - two escapes for one letter. That is correct, and it is why an encoded string can be dramatically longer than it looks. The related trap is double-encoding, shown as its own output: run an already-encoded string through an encoder again and every % becomes %25, so %20 turns into %2520.

More encoding & developer tools