URL Encoding: Percent-Encoding Rules & Examples

Key Takeaways

Percent-encoding: byte → %XX; space = %20, & = %26, = = %3D, # = %23, Chinese chars = 3 UTF-8 bytes each

Two encoders: encodeURIComponent escapes & = / ? (for values); encodeURI keeps them (for full URLs)

Form quirk: application/x-www-form-urlencoded uses + for spaces, not %20

Double-encoding bug: %20 encoded again → %2520 — the classic broken-link signature

Core answer: URL encoding (percent-encoding) replaces unsafe characters with %XX hex bytes: space → %20, # → %23, % → %25, Chinese "中" → %E4%B8%AD (its 3 UTF-8 bytes). Reserved characters keep their meaning: ? starts the query, & separates params, = assigns, # starts the fragment. Encode component VALUES, never the whole URL — encoding the ? and & destroys the structure.

The reserved vs safe lists

Reserved (structural — encode inside values): : / ? # [ ] @ ! $ & ' ( ) * + , ; =

Unreserved (never encode): A–Z a–z 0–9 − _ . ~

Char	Encoded	Why
space	%20 (+ in forms)	breaks parsing
#	%23	starts fragment
&	%26	param separator
=	%3D	key-value separator
%	%25	the escape char itself
中	%E4%B8%AD	UTF-8 bytes E4 B8 AD

+ vs %20: the form-data quirk

application/x-www-form-urlencoded encodes space as +; raw URLs use %20. A "+" in a query VALUE must be %2B, or servers read it as a space. This 40-year-old wart still bites APIs daily.

Worked examples

Example 1 — Search query. "C++ 教程" as a q parameter: q=C%2B%2B%20%E6%95%99%E7%A8%8B — the + signs encoded as %2B, space as %20, Chinese as UTF-8 bytes.

Example 2 — The double-encoding bug. Encoding "a b" twice: %2520 (the % of %20 got encoded to %25). If users see %25xx in your logs, something encoded twice — encode once, at the boundary.

Example 3 — Passwords in redirects. A redirect URL containing ?next=/dashboard?tab=2 must encode the inner URL: ?next=%2Fdashboard%3Ftab%3D2 — or the outer parser eats the inner query.

Example 4 — decodeURIComponent errors. URIError: malformed URI — input had a lone % (like "100% off" unencoded). Server-side: always wrap decode in try/catch; client-side: validate before decoding.

Common mistakes and myths

Encoding the whole URL — encodeURIComponent("https://a.com/?q=1") breaks everything; encode values, assemble structure.
Forgetting path vs query rules — / is legal (structural) in paths but must be %2F inside a path SEGMENT value (user names with slashes).
Assuming servers agree — some frameworks auto-decode once, some twice; know your stack's behavior before pre-decoding.
IDN confusion — international domains use punycode (xn--fiq228c.com for 中文.com), not percent-encoding — different layer entirely.
Security blind spots — WAFs and filters can be bypassed with double-encoded payloads (%2527 → decodes to %27 → decodes to '); security layers must decode fully before matching.

Frequently Asked Questions

What is URL percent-encoding?

Any byte that cannot safely appear in a URL becomes % followed by its hex value: space → %20, & → %26, = → %3D, ? → %3F, # → %23, % itself → %25. Non-ASCII text encodes as its UTF-8 bytes: 中 = 0xE4 0xB8 0xAD → %E4%B8%AD (3 bytes per CJK char). URLs were designed for ASCII — encoding is the tunnel for everything else.

Which characters must be encoded?

Unreserved (never encoded): A-Z a-z 0-9 and − _ . ~. Reserved (encode when used as DATA): : / ? # [ ] @ ! $ & ' ( ) * + , ; = — they have structural meaning. Everything else (spaces, Unicode, control bytes): always encode. In practice: parameter values containing & = ? # / space or non-ASCII WILL break the URL if sent raw.

encodeURI vs encodeURIComponent — which do I use?

encodeURIComponent escapes EVERYTHING structural (& = / ? :) — use it for each parameter VALUE: "?q=" + encodeURIComponent(input). encodeURI preserves URL structure — use it only on a complete URL with Unicode. Composing: build the URL from encoded parts, never encodeURI the assembled string (it leaves your injected & intact) and never encodeURIComponent the whole URL (it eats the :// and path slashes).

How do Chinese characters work in URLs?

Each CJK character is 3 bytes in UTF-8 → 9 percent-encoded chars: 你好 → %E4%BD%A0%E5%A5%BD. Browsers display decoded characters but copy the encoded form — both are the same resource. Practical notes: keep slugs ASCII for portability (pinyin or English); if Chinese paths are used, ensure the server and CMS decode consistently; some legacy systems use GBK bytes instead — the mojibake source.

What is double encoding and why does it break links?

Encoding an already-encoded string: %20 → %2520 (the % itself becomes %25). Symptom: URLs showing literal %2520, decoders yielding "a%20b" instead of "a b". Causes: encoding at both client and server; frameworks that auto-encode plus manual encodeURIComponent; CMS pipelines re-saving URLs. Fix: encode exactly ONCE at the boundary where the URL is built; decode once when consuming.

What mistakes happen with URL encoding?

(1) Raw & or = in query values (splits parameters); (2) + treated as space everywhere — it means space ONLY in query strings (form encoding), in paths it is a literal plus; (3) encoding the whole URL with encodeURIComponent; (4) forgetting to decode before comparing/store; (5) % in passwords/tokens breaking hand-built URLs; (6) assuming visible Chinese in the address bar needs no encoding (the network layer still needs the bytes); (7) fragment (#) content sent to servers — it is not: fragments stay client-side.

Input

Output