URL encoding — why a single character turns into %E6%97%A5
Only a small set of characters is allowed in a web address: letters, digits, and a handful of punctuation marks. Spaces are not on the list, and neither is any character outside plain English. To travel in a URL they have to be rewritten in characters that are. That rewriting is percent-encoding.
Copy a link from the address bar and it looks readable. Paste the same link into code or a document and it breaks halfway through. The browser draws a friendly version on screen for you to read, but the address it actually sends to the server looks different. Click into the address bar and copy from there and you see the real one.
Percent-encoding replaces a disallowed character with a % followed by the hexadecimal value of its bytes. A space becomes %20, a question mark becomes %3F. Nothing is lost — applying the rule backwards returns exactly what you started with.
Why one character becomes three chunks
Percent-encoding carries bytes, not characters, so the text has to become bytes first. On the modern web that conversion is UTF-8.
In UTF-8 an English letter is one byte, but most characters outside the Latin alphabet take three. The Japanese character 日 is the bytes 230, 151, 165 — E6, 97, A5 in hexadecimal — so it encodes as %E6%97%A5. The same is true of Korean, Chinese, and most symbols; emoji usually take four bytes and so produce four chunks.
This gives you a rough reading aid: groups of three usually mean a non-Latin character, while a lone % followed by a value starting with 2 or 3 is usually a space or a punctuation mark.
“Whole address” and “single value” do different jobs
There are two buttons not because there are two kinds of encoding, but because there are two kinds of thing you might paste.
If you pasted an entire address, then ://, ? and & are its skeleton. Escape those and the result is correctly encoded but no longer an address. “Whole address” leaves the skeleton alone and rewrites only what cannot appear literally.
For a single value going into a query string the opposite is true. If the search term is “A&B” and the & survives, the server reads it as the start of another parameter: the search term becomes “A” and a stray parameter “B” appears out of nowhere. “Single value” escapes the separators too, which is what prevents that.
Same character, different result
Where the two modes actually diverge.
| Character | Whole address | Single value |
|---|---|---|
| space | %20 | %20 |
| 日 | %E6%97%A5 | %E6%97%A5 |
| : colon | left as : | %3A |
| / slash | left as / | %2F |
| ? question mark | left as ? | %3F |
| & ampersand | left as & | %26 |
| = equals | left as = | %3D |
| # hash | left as # | %23 |
| % percent | %25 | %25 |
Domain names are not percent-encoded
One part of an address follows a different rule. Paths and query strings use percent-encoding, but the domain name uses punycode, which turns it into an ASCII name beginning with xn--.
The domain 日本語.jp becomes xn--wgv71a119e.jp. Percent-encoding it instead produces something that looks plausible and resolves to nothing, because no such host exists. In “whole address” mode this tool converts the domain to punycode and percent-encodes the rest, so the output matches the address your browser would actually send.
When + means a space, and when it does not
Sometimes a space appears as + rather than %20. That comes from a separate rule used when submitting forms (application/x-www-form-urlencoded), and it is common in the query strings that search boxes generate.
The catch is that a + inside a path is a literal plus. A tool that always converts + to a space is wrong half the time, and so is one that never does. When decoding, if the input contains a + and the two readings differ, this tool shows both. Pick the space reading for anything that came from a form or a search box, and the literal reading for file names and paths.
Common mistakes
- •Encoding an address that is already encoded — %E6 becomes %25E6 and the link goes nowhere. The tool warns when the input already contains %xx.
- •Running a whole address through “single value” — valid output, but a long string that cannot be used as a link.
- •Leaving & inside a value — the value is cut short and the rest is read as a separate parameter.
- •Decoding text like “50% off” — there are no hex digits after the %, so it fails. To put that text in a URL the % has to become %25.
- •Reading an encoded URL by eye — you cannot tell what %E6%97%A5 says without decoding it.
Frequently asked questions
My address bar shows the characters normally. Why?
That is display only. Click into the address bar and copy, and you get the percent-encoded form. The encoded version is what travels to the server.
Should I use %20 or + for a space?
Use %20 in a path. In a query string both are usually read as a space, but %20 is the safer choice when you are not sure how the far end parses it.
My decoded text came out as garbage.
The URL may be old and built with a non-UTF-8 encoding such as Shift_JIS or EUC-KR. A telltale sign is non-Latin text arriving in chunks of two rather than three.
Is anything I paste stored?
No. The conversion runs entirely in your browser and nothing is sent anywhere.