Chinese Turns Into %E4%B8%AD (Percent Encoding) in a URL — Is That Normal?

Symptom: Chinese becomes a string of %XX

You copy https://example.com/search?q=中文 somewhere and the Chinese turns into https://example.com/search?q=%E4%B8%AD%E6%96%87. Rest assured: this is completely normal, not mojibake.

Why Chinese must be encoded into %XX

URL spec (RFC 3986) only allows a small set of ASCII characters directly in an address (letters, digits, and a few symbols). Chinese, spaces, and emoji are not on the whitelist. To fit any character into a URL, percent-encoding was invented:

• Convert the character to UTF-8 bytes;
• Write each byte as % + two hex digits.

So "中" in UTF-8 is three bytes E4 B8 AD, which becomes %E4%B8%AD.

A typical CJK character expands to about nine ASCII characters (3 bytes × %XX each). That is why Chinese paths look intimidating in logs, SMS, and QR codes — the shape changed; the meaning did not.

How to decode it back

Reverse the process: restore UTF-8 from %XX bytes. Open ToolVault's URL encoder/decoder:

1. Paste the %XX-laden string;
2. Click Decode — readable Chinese appears;
3. Click Encode to turn Chinese into a legal URL fragment;
4. All processing is local, nothing uploads.

To analyze a full URL (protocol, path, individual query parameters), prefer the URL Params Parser or URL Parser.

Implementer's note

This site's encoder is a thin encodeURIComponent / decodeURIComponent wrapper:

• Chinese and emoji are UTF-8 percent-encoded; the deprecated escape() path (illegal %uXXXX) is never used.
• Spaces encode as %20; decode does not treat + as space. If a copied query uses +, use a params parser (URLSearchParams), not bare decodeURIComponent.
• Truncated % sequences throw and surface in the output pane — common after SMS truncation or gateway double-encoding.

For printable binary vs URI escaping, see Base64; for JWT's Base64URL alphabet, see Base64 vs Base64URL.

When to be careful

• Path vs query: both /搜索 and ?q=搜索 can be encoded; unencoded forms may be rejected.
• Ambiguity of +: application/x-www-form-urlencoded treats + as space; RFC 3986 treats + as plus. Prefer %20 when you encode yourself; know which decoder the other side uses.
• Reserved chars: ? & = / # are structural. Classic bug: concatenating user input into ?redirect= without encodeURIComponent lets & cut off later parameters.
• Double encoding: twice-encoded %E4 becomes %25E4; one decode still shows %. Decode again if residue remains, but cap the loop.

Frontend handling: encodeURI vs encodeURIComponent

// Right: whole URL with encodeURI
encodeURI('https://a.com/search?q=word')   // structure kept; non-ASCII escaped

// Right: parameter value with encodeURIComponent
const q = 'a&b=c';
`https://a.com/search?q=${encodeURIComponent(q)}`
// https://a.com/search?q=a%26b%3Dc

// Wrong: encodeURIComponent on a whole URL destroys ://
encodeURIComponent('https://a.com')   // https%3A%2F%2Fa.com

Decode with matching decodeURI / decodeURIComponent. Lone % throws URIError — production code needs try/catch.

Address bar vs the wire

Modern browsers often display Chinese paths as characters while HTTP still carries percent-encoding. Copy from the address bar may yield Han characters; copy from DevTools or server logs yields %XX. "Works in the browser, breaks in my script" is usually a second encode (or a missing one). Align on the wire form with the encoder. Path vs query space rules also differ — see spaces and special chars and the encoder guide.

SEO and Chinese URLs

Readable Chinese paths help some SERP contexts but bloat logs, shorteners, and QR codes. Many Chinese sites keep ASCII slugs and put language in the page title/body — identifiers stay stable across tools. Both forms work in modern browsers and crawlers; pick one convention and stay consistent.

FAQ

Why do some sites show Chinese directly while others show %XX?

Depends on whether the browser/server does a display-layer decode. Transmission is still encoded underneath.

Will the encoded link still open normally?

Yes. Servers decode %E4%B8%AD back to "中". When logs mix both forms, normalize before deduping or aggregating.

Is Base64 the same as URL encoding?

No. URL encoding percent-escapes bytes for URIs; Base64 turns arbitrary data into printable text (Base64 tool). The base64url variant swaps +/ for -_ and drops padding — the URL-safe alphabet used inside JWTs.

The API received Chinese as %XX — should I decode before storing?

It depends on the framework. Express/Koa/Spring often auto-decode query parameters; path segments and bodies vary. Print what arrived — if %XX remains, decode once at the entry point with decodeURIComponent, not in every business handler.

Double-encoding: the %25E4 smell

When logs show %25E4%25B8%25AD instead of %E4%B8%AD, something encoded an already-encoded string (% → %25). Common sources: putting encodeURIComponent output into another API that encodes again, or copying a display-decoded URL back through a form that encodes on submit. Fix by decoding once to Unicode at the boundary you control, then encoding once when you build the next hop. The URL encoder “peel layers” mode is useful for seeing how many times a sample was wrapped.

Form bodies vs query strings

application/x-www-form-urlencoded historically turns spaces into +, while query strings in modern URLSearchParams still percent-encode spaces as %20. Chinese characters are percent-encoded in both, but mixing parsers (treat + as space in one place and literally in another) corrupts adjacent ASCII fields and makes CJK look “fine” while & / = break. Keep one decoding policy per hop; document it next to the route.

Provided by ToolVault. Related tools: URL Encode/Decode, URL Params Parser, Base64 Encode/Decode, JWT Decoder. Visit the home page for more developer tools.