Which result should I use?

The value form for anything going after "?q=" or into a single path segment. The whole-URL form when you are handling a complete URL. If you are unsure, ask whether the "/" and "?" characters in your string are acting as separators: if they are, use the URL form; if they are just characters, use the value form.

Can I use Japanese filenames in URLs?

Encoded, yes — but it is not advisable. They get double-encoded when shared onward, and older software that cannot interpret %XX renders the name as garbage. Filenames for distribution are less trouble later when kept to letters, digits and hyphens.

A long URL in an email breaks in the middle.

That is the mail client wrapping the line, not an encoding problem — though URLs containing Japanese are longer because of %XX and so hit it sooner. Wrapping the URL in angle brackets, , or using a shortener avoids the break.

Is the text I paste stored?

No, and nothing is sent. The conversion happens in the page and is gone when you close it.

Why one Japanese character becomes three %XX groups

Only part of ASCII can travel in a URL, so anything else is turned into bytes first and each byte is rewritten as %XX. In UTF-8, kana and kanji are generally three bytes, so one character arrives as something like %E3%81%82. Most emoji are four bytes and produce four groups. That is why a URL carrying a Japanese query looks so long — nothing is broken.

What double encoding looks like

Encoding an already-encoded string turns the "%" itself into "%25": %E3%81%82 becomes %25E3%2581%2582, and decoding that returns the literal text "%E3%81%82" rather than the original characters. Seeing %E3%81%82 printed on a page after following a link is almost always this. Decoding twice recovers the original, which you can confirm by feeding the result back into the input here.

%20 is correct in paths and queries. Reading "+" as a space is a convention specific to form submissions; inside a path, "+" is a literal plus. The same character therefore means different things in different places. When assembling a URL by hand, use %20 and its meaning will not change with position.

Characters that need no encoding

A-Z, a-z, 0-9 and the four characters - . _ ~ are "unreserved" and can be placed as they are; the tool leaves them alone. The characters ! * ' ( ) are technically permitted in some positions but handled inconsistently in practice, so they are encoded when producing the value form. If you get to choose the characters in a filename or an identifier, staying inside the unreserved set removes the question entirely.

Back to all tools／ Text & data

URL Encode / Decode

Runs in your browserNothing is uploaded

Turn text with non-ASCII characters or symbols into %XX form for URLs. Encoding a value differs from encoding a whole URL, so both are shown. Decode %E3%81%82-style strings back to readable text.

Input

Direction

Input

Output

Enter text and the conversion appears here.

The same string encodes differently depending on whether it is a value inside a URL or a whole URL. As a value, "/" and "?" are escaped too; as a URL, the separators are left as separators.

All tools

Why this one

Both results, side by side: The same string encodes differently depending on whether it is a value inside a query or a whole URL being passed along. As a value, "/", "?", "&" and "=" all become %XX; as a URL, they stay as separators. Both are shown rather than making you choose first, because confusing the two is the single most common cause of URL bugs.
You choose what "+" means: In form submissions (application/x-www-form-urlencoded) a space is written as "+", while a "+" in a URL path is a literal plus sign. Being able to switch how it is read on decode covers both "the spaces are still plus signs" and "my plus signs turned into spaces".
Broken input is not thrown away: Given a truncated sequence like "%E3%81", most tools raise an error and return nothing. Here the readable part is decoded, the broken part is left as it is, and the page says so. When you are examining a string pulled out of a log, knowing how far it decoded beats knowing that it failed.

How to use

Pick a direction
Encode (text to %XX) or decode (%XX back to text).
Paste the string
It converts as you type. Encoding shows both the "as a value" and "as a whole URL" results at once.
Copy the one you need
Each result has its own copy button. Which one to use depends on whether the destination is a query value or a complete URL.

Good to know

Why one Japanese character becomes three %XX groups: Only part of ASCII can travel in a URL, so anything else is turned into bytes first and each byte is rewritten as %XX. In UTF-8, kana and kanji are generally three bytes, so one character arrives as something like %E3%81%82. Most emoji are four bytes and produce four groups. That is why a URL carrying a Japanese query looks so long — nothing is broken.
What double encoding looks like: Encoding an already-encoded string turns the "%" itself into "%25": %E3%81%82 becomes %25E3%2581%2582, and decoding that returns the literal text "%E3%81%82" rather than the original characters. Seeing %E3%81%82 printed on a page after following a link is almost always this. Decoding twice recovers the original, which you can confirm by feeding the result back into the input here.
Is a space %20 or +?: %20 is correct in paths and queries. Reading "+" as a space is a convention specific to form submissions; inside a path, "+" is a literal plus. The same character therefore means different things in different places. When assembling a URL by hand, use %20 and its meaning will not change with position.
Characters that need no encoding: A-Z, a-z, 0-9 and the four characters - . _ ~ are "unreserved" and can be placed as they are; the tool leaves them alone. The characters ! * ' ( ) are technically permitted in some positions but handled inconsistently in practice, so they are encoded when producing the value form. If you get to choose the characters in a filename or an identifier, staying inside the unreserved set removes the question entirely.

FAQ

Which result should I use?: The value form for anything going after "?q=" or into a single path segment. The whole-URL form when you are handling a complete URL. If you are unsure, ask whether the "/" and "?" characters in your string are acting as separators: if they are, use the URL form; if they are just characters, use the value form.
Can I use Japanese filenames in URLs?: Encoded, yes — but it is not advisable. They get double-encoded when shared onward, and older software that cannot interpret %XX renders the name as garbage. Filenames for distribution are less trouble later when kept to letters, digits and hyphens.
A long URL in an email breaks in the middle.: That is the mail client wrapping the line, not an encoding problem — though URLs containing Japanese are longer because of %XX and so hit it sooner. Wrapping the URL in angle brackets, <https://…>, or using a shortener avoids the break.
Is the text I paste stored?: No, and nothing is sent. The conversion happens in the page and is gone when you close it.

Input

Output

Related tools

Why this one

How to use

Pick a direction

Paste the string

Copy the one you need

Good to know

FAQ