URL Encoding (Percent-Encoding) Guide: Why Text Turns Into %20 and %EC%95%88
Copy a link containing a non-English search term and you get strings like %EC%95%88%EB%85%95. That is URL encoding. This guide explains the rules behind it and the problems it causes in web development, marketing links and API integrations.
Only some characters are allowed in a URL
URL syntax is defined in RFC 3986. Only letters, digits and four symbols—hyphen (-), period (.), underscore (_) and tilde (~)—can appear in a URL as-is. These are called unreserved characters.
Symbols such as :, /, ?, #, & and = are reserved: they give a URL its structure. ? starts the query string, & separates parameters and # marks a fragment. If a search term itself contains & or #, inserting it unencoded changes the meaning of the whole URL.
How percent-encoding works
Characters that cannot appear directly are split into bytes, and each byte is written as % followed by two hexadecimal digits. A space (byte 0x20) becomes %20, an ampersand (0x26) becomes %26 and an equals sign (0x3D) becomes %3D.
Non-ASCII text is first converted to UTF-8 bytes and then encoded the same way. The Korean syllable 안 is three bytes in UTF-8 (EC 95 88), so it becomes %EC%95%88. One character turns into nine.
안녕 하세요? → %EC%95%88%EB%85%95%20%ED%95%98%EC%84%B8%EC%9A%94%3F
a b&c=d → a%20b%26c%3Dd
Decoding reverses the process: %EC%95%88 becomes the bytes EC 95 88, which are interpreted as UTF-8. If a server interprets those bytes in a legacy encoding instead, the text is garbled—a common cause of broken search terms on older websites.
Is a space %20 or +?
Spaces cause the most confusion. Under RFC 3986 a space is %20. However, the application/x-www-form-urlencoded format used by HTML forms writes spaces in query strings as +. The same text a b can therefore appear as a%20b in a path and as a+b in a form query.
The trouble starts when you need a literal plus sign. A phone number like +82 or an expression like 1+1 placed unencoded in a query may be read as a space. Encode such values as %2B. Libraries differ—JavaScript's encodeURIComponent produces %20, while some server libraries produce +—so make sure both sides use the same convention.
Encode components, not whole URLs
Never encode an entire URL in one go. Encoding https://example.com/search?q=... turns : and / into %3A and %2F, and the result no longer works as an address. Apply encoding only to the parts that are data, such as parameter values.
JavaScript reflects this with two functions. encodeURI leaves structural characters alone, while encodeURIComponent also encodes /, ?, & and =. For query parameter values, encodeURIComponent is the safe choice.
Double encoding: be suspicious of %2520
Encoding an already encoded string turns % into %25. If a space appears as %2520 instead of %20, it has been encoded twice. This often happens with tracking links that pass through several redirects or with login return URLs that carry another URL as a parameter.
Decoding twice is just as harmful: a genuine %25 in the data becomes % and the value changes. The rule is simple—encode once at the last moment when a value goes into a URL, and decode once at the first moment when you read it.
Practical checklist
Try values in the AIBIZAP URL encoder/decoder to see exactly which characters change and how.
- Encode campaign names in UTM links if they contain spaces or non-English text.
- Encode API values such as search terms, email addresses (with @) and timestamps (with :) at the component level.
- If a link breaks, look for %25 to detect double encoding.
- If server logs show garbled text, confirm that values were decoded and interpreted as UTF-8.
- When a Base64 value must go into a URL, use Base64URL or percent-encode the result.