URL Encoder & Decoder

Encode and decode URLs

Choose whether you are encoding a value that will sit inside a URL or a whole URL, pick a direction, and paste your text. The swap button sends the result back as the input and flips the direction, which is the fastest way to check that something round-trips.

Everything runs in your browser. Nothing is uploaded, stored or logged, and the text is never written into the page address.

What percent-encoding is

A URL has a fixed grammar. Slashes separate path segments, ? begins the query, & separates parameters, # starts the fragment. Characters that carry meaning cannot also appear as ordinary data without confusing whatever is parsing the URL — and a space cannot appear at all.

Percent-encoding solves this by replacing a character with % followed by its byte value in hexadecimal. A space becomes %20, & becomes %26, / becomes %2F. The URL still says what it meant; it just no longer collides with its own punctuation.

The distinction that actually matters

There are two encoders, and picking the wrong one is the most common mistake in this whole area.

A value inside a URL escapes the structural characters too — / ? # & = : — because at that point they are part of your data, not part of the address. This is what you want when inserting a search term, an email address, a redirect target or a filename into a URL.

A whole URL leaves those characters alone, because there they really are structure. This is for tidying a link that is already assembled and happens to contain a space or an accented character.

Run a complete URL through the value encoder and you get this:

https%3A%2F%2Fexample.com%2Fa%20b%3Fq%3D1

Every structural character has been escaped, so it is no longer a link at all — merely a string that happens to describe one. It is correct if you are placing that URL inside another URL as a parameter, and useless if you meant to link to it.

The bug this prevents

Suppose you build a link with a name in it:

/search?name=Tom & Jerry&page=2

The server sees three parameters: name is “Tom “, then something called ” Jerry”, then page. The value silently broke the URL because it contained the character that separates parameters.

Encode the value first and the ampersand becomes %26:

/search?name=Tom%20%26%20Jerry&page=2

Now there are two parameters and name is intact. The rule that follows: encode each value individually, then assemble the URL. Never assemble the URL and then encode the whole thing — by that point the tool cannot tell your data from the URL’s punctuation.

%20 or +?

Both appear in the wild and they are not interchangeable. %20 is the correct encoding of a space anywhere in a URL.

The + form belongs to one specific format, application/x-www-form-urlencoded, which is what a browser submits an HTML form as. It is valid in that context and not valid in a URL path, where a + is a literal plus sign.

This tool always produces %20. If you are decoding a form submission that uses + for spaces, replace those yourself before decoding.

Non-English characters

Characters outside ASCII are first converted to UTF-8 bytes, and then each byte is percent-encoded. So “café” becomes caf%C3%A9 — the accented letter is two bytes, so it produces two escapes.

This is what the standard requires, and it is why a URL containing non-Latin text looks so much longer than the text it carries: “日本” is six bytes and nine encoded characters per character.

When decoding fails

One thing is genuinely malformed: a % that is not followed by two hexadecimal digits. It usually means a literal percent sign was included without being encoded — a literal % must be written %25 — or that the string was cut off partway through an escape.

The tool reports this rather than guessing, because guessing would mean either dropping the character or inventing a byte, and both produce a value that is quietly wrong.

Frequently asked questions

What is URL encoding?

Also called percent-encoding: characters that cannot appear literally in a URL are replaced by a % followed by their byte value in hexadecimal. A space becomes %20, an ampersand becomes %26. It is how a URL carries data that would otherwise break its own structure.

What is the difference between the two encoding modes?

A value inside a URL also escapes / ? # & = :, because inside a query string those are data, not structure. A whole URL leaves them alone, because there they are the structure. Using the first on a complete URL escapes the :// and produces a link no browser will follow.

Which mode do I want?

Almost always the value mode. You want it any time you are inserting something into a URL: a search term, an email address, a redirect target, a name containing a space. Whole-URL mode is for cleaning up a link that is already assembled and merely contains a stray space or accented character.

Why did my query parameter split in two?

Because the value contained an unescaped &. In ?name=Tom & Jerry the browser reads & Jerry as the start of a second parameter. Encoding the value first turns it into %26, and it stays one parameter. This is the single most common URL-encoding bug.

Should a space be %20 or +?

%20 is correct everywhere in a URL. The + form is specific to application/x-www-form-urlencoded — HTML form submissions — and is not valid in a URL path. This tool always produces %20; when decoding a form-style string, replace + with a space yourself first.

Why won't it decode my string?

It contains a broken escape: a % that is not followed by two hexadecimal digits. That usually means a literal percent sign was included without being encoded, or the string was truncated. A literal % must itself be written as %25.

Does this handle non-English characters?

Yes. Characters outside ASCII are converted to UTF-8 bytes and each byte is percent-encoded, which is what the URL standard requires — so "café" becomes caf%C3%A9, two escapes for the one accented letter.