You copy a link and send it to a friend, but it pastes back as a string of %E4%B8%AD%E6%96%87. Or you see search?q=hello%20world in the address bar — why did the space become %20? That is not garbage; it is URL encoding at work. This post explains in plain English what it is, why it appears, and how to reverse it fast.
1. What exactly is URL encoding
URL encoding, formally percent-encoding, is a rule that turns "characters that cannot appear directly in a URL" into a safe form. The method is simple: take the byte of a character and write it as "% + two hex digits". A space is byte 0x20, so it becomes %20.
Why this rule? A URL has "syntax": ? starts parameters, & separates them, / separates paths, # is an anchor. If your parameter value contains these symbols, the browser and server will misread it. URL encoding wraps those ambiguous characters in a safe coat so they are treated as plain data, not URL structure.
2. Why spaces specifically become %20
The URL spec says: no spaces allowed in a URL. A space can be trimmed or ignored, breaking the link. So the space must be encoded — its ASCII byte is decimal 32, hex 20, hence %20.
You may also see a space written as +, e.g. q=hello+world. That is a historical convention: in application/x-www-form-urlencoded (form submit), a space is +. Same meaning, different context — use %20 in the path, + may appear in query params (forms). A common beginner trap: decoding a + in a path as a space causes errors.
3. Why Chinese becomes a long %E4%B8%AD string
English letters, digits, and - _ . ~ are "safe characters" and need no encoding. But Chinese, Japanese, emoji are not safe and must be encoded.
Modern spec (RFC 3986) requires converting non-ASCII text to bytes with UTF-8 first, then percent-encoding each byte. One non-ASCII character is usually 2–4 bytes in UTF-8, so it becomes several groups of "%xx". For example, "é" is %C3%A9 and "€" is %E2%82%AC—just their bytes written out. Scary-looking, but harmless.
Side note: if your decoded text shows as real mojibake (weird chars like "é", not question-mark boxes), the encoder and decoder likely used different charsets (one UTF-8, one Latin-1). Stick to UTF-8 and most mojibake disappears.
4. encodeURI vs encodeURIComponent — don't mix them up
Coders meet these two JavaScript functions; the difference is the root of many bugs:
- encodeURI: encodes "a whole complete URL", keeping
: / ? # & =as structure symbols, because the whole URL still needs them. - encodeURIComponent: encodes "a single parameter value inside a URL", encoding
/ ? & =too, so the value's symbols don't break the URL structure.
One-line memory: use encodeURIComponent for parameter values, encodeURI for a whole URL. If you stuff a parameter value with & into a URL without encoding, the server reads it as a separator and drops everything after.
5. Convert instantly with Jisubao's online tool
Once you know the theory, you don't need to code. Use Jisubao's free tool for both directions in a second:
- Open the Jisubao URL Encode/Decode tool;
- Paste text with Chinese or special symbols, click "Encode", get
%xxform instantly, ready to drop into a URL; - Reverse: paste a string like
%E4%B8%AD%E6%96%87and click "Decode", back to human-readable text; - Copy the result in one click — handy for debugging links and API params.
The tool runs locally in your browser; input is never uploaded. Free, no signup, open and use.
6. Quick FAQ
Q: Why is it still garbled after decode? — The source was likely GBK; confirm the charset or decode as UTF-8 again.
Q: %20 or +, which is right? — %20 is safest in the path; in form query params both + and %20 mean space.
Q: Encode the whole URL? — No. Only encode the "parameter value" part that may contain special chars, with encodeURIComponent; keep the structure symbols.
URL encoding looks mysterious, but it is just "writing unsafe URL characters honestly as % + hex". Get the space, Chinese, and the two encode functions, and leave the rest to the tool.
👉 Try it now: Jisubao online URL Encode/Decode tool →