URL Encoding Guide: encodeURIComponent vs encodeURI & Special Characters

URL encoding (also known as Percent-Encoding) is one of the most fundamental yet error-prone aspects of web development. What seems like simply "turning special characters into %XX" involves the RFC 3986 standard, differences across programming languages, and numerous pitfalls.

This guide will start from the underlying principles and thoroughly explain every aspect of URL encoding, helping you avoid common encoding mistakes in real-world development.

1. How URL Encoding Works

URLs (Uniform Resource Locators) only allow a subset of the ASCII character set. Specifically, URL characters fall into two categories:

• Reserved Characters: Characters with special meaning, such as :/?#[]@!$&'()*+,;=
• Unreserved Characters: Safe characters that can be used directly, including letters (A-Z a-z), digits (0-9), and -_.~

When a URL needs to include characters outside this range (such as non-ASCII characters, spaces, or special symbols), URL encoding is required. The encoding rule is simple: convert each byte to hexadecimal and prefix it with a percent sign %.

For example:

"Hello" → "%E4%BD%A0%E5%A5%BD"
"hello world" → "hello%20world"
"a+b=c" → "a%2Bb%3Dc"
"a&b" → "a%26b"

1.1 Why Do We Need URL Encoding?

URLs were originally designed to identify internet resources. Reserved characters have different meanings in different parts of a URL:

• / Separates path segments
• ? Separates path from query parameters
• & Separates query parameters
• = Separates parameter names from values
• # Separates path from fragment identifier
• % Marks the start of an encoded character

If user input contains these characters but they are not intended as delimiters, they must be encoded. Otherwise, URL parsing will break.

2. JavaScript Encoding Functions

JavaScript provides three URL encoding-related functions. Their differences are among the most common interview questions and one of the most easily confused areas in real-world development.

2.1 encodeURI()

encodeURI() is used to encode a complete URL. It does not encode URL reserved characters because they have special meaning in the URL structure.

encodeURI("https://example.com/path/file?q=test")
// → "https://example.com/%E8%B7%AF%E5%BE%84/%E6%96%87%E4%BB%B6?q=%E6%B5%8B%E8%AF%95"
// Note: ://? reserved characters are not encoded

encodeURI("https://example.com/search?q=hello world&lang=en")
// → "https://example.com/search?q=hello%20world&lang=en"
// Note: & and = are not encoded

2.2 encodeURIComponent()

encodeURIComponent() is used to encode URL components (such as query parameter values, path segments). It encodes all characters except letters, digits, and -_.!~*'().

encodeURIComponent("hello world")
// → "hello%20world"

encodeURIComponent("a&b=c")
// → "a%26b%3Dc"
// & and = are encoded! 

encodeURIComponent("https://example.com")
// → "https%3A%2F%2Fexample.com"
// :// is also encoded! This is why you should not use it on complete URLs

2.3 Key Differences

2.4 escape() (Deprecated)

escape() has been deprecated and should no longer be used. It does not encode characters like @*_+-./ and uses a non-standard encoding format (%uXXXX) for Unicode characters that does not comply with RFC standards.

3. Encoding Rules in Detail

3.1 Spaces: + or %20?

This is the most common point of confusion in URL encoding. The rules are:

• URL path segment: Spaces should be encoded as %20
• application/x-www-form-urlencoded query params: Spaces can be encoded as + or %20
• JavaScript encodeURI/encodeURIComponent: Spaces are encoded as %20
• HTML forms: Spaces are encoded as +

3.2 Unicode Character Encoding

For Unicode characters (Chinese, Japanese, emoji, etc.), URL encoding first converts the character to a UTF-8 byte sequence, then percent-encodes each byte:

"you" → UTF-8: E4 BD A0 → "%E4%BD%A0"
"♥" → UTF-8: E2 99 A5 → "%E2%99%A5"
"😀" → UTF-8: F0 9F 98 80 → "%F0%9F%98%80"

3.3 Common Special Character Reference

4. Common Issues in Real-World Development

4.1 Double Encoding

Double encoding means data gets encoded twice, resulting in incorrect output after decoding. This typically happens when both frontend and backend encode without proper coordination:

// First encoding
encodeURIComponent("hello world") → "hello%20world"
// Second encoding (wrong!)
encodeURIComponent("hello%20world") → "hello%2520world"
// Decoding once gives "hello%20world" instead of "hello world"

Solution: Clearly define encoding responsibility boundaries — the frontend encodes parameter values once, and the backend decodes once upon receipt.

4.2 Server-Side URL Encoding

URL encoding behavior differs across languages and frameworks:

4.3 Encoding and Security

URL encoding is not just about making URLs valid — it is also an important defense against URL injection attacks:

• Open Redirect prevention: Encoding user-provided URL parameters can prevent redirect attacks
• SSRF prevention: Encoding special characters can block server-side request forgery
• Log security: Encoded URLs in logs won't contain special characters that could enable log injection

5. URL Encoding Best Practices

1. Use encodeURIComponent for parameter values: Not encodeURI for the entire URL
2. Encode once on frontend, decode once on backend: Avoid double encoding
3. Standardize encoding: Agree on encoding conventions when collaborating across languages
4. Use framework built-ins: Most modern web frameworks (like axios, fetch, React Router) handle URL encoding automatically
5. Test edge cases: Pay special attention to non-ASCII characters, emoji, and special symbols

Conclusion

URL encoding may seem simple, but it involves many details in real-world development. Remember the core principle: use encodeURI() for complete URLs, encodeURIComponent() for URL components. When you encounter encoding issues, first check whether double encoding occurred or the wrong encoding function was selected.