What is URL Encoding and Why Does It Matter?

You have probably seen strings like hello%20world or %3Fquery%3Dvalue in URLs. That is URL encoding (also called percent encoding) in action. It is a fundamental mechanism of the web, and understanding it will help you debug broken links, build correct API requests, and avoid subtle bugs in your applications.

Why URL Encoding Exists

URLs can only contain a limited set of characters from the ASCII character set. Characters like spaces, question marks, ampersands, and non-ASCII characters (such as accented letters or emoji) have special meanings or are simply not allowed in URLs. URL encoding provides a way to represent these characters safely by replacing them with a percent sign followed by two hexadecimal digits representing the character's byte value.

For example, a space becomes %20, a question mark becomes %3F, and the ampersand becomes %26. Multi-byte UTF-8 characters produce multiple percent-encoded bytes.

Reserved vs. Unreserved Characters

RFC 3986 divides URL characters into two groups:

• Unreserved characters do not need encoding. These are: A-Z a-z 0-9 - _ . ~
• Reserved characters have special meaning in URLs: : / ? # [ ] @ ! $ & ' ( ) * + , ; =. These must be percent-encoded when used in a context where their special meaning is not intended.

The key point is context. A / is perfectly valid as a path separator, but if a file name literally contains a slash, that character must be encoded as %2F.

When Encoding Happens Automatically

Browsers automatically encode URLs when you type them in the address bar or when they appear in HTML attributes like href. Form submissions with application/x-www-form-urlencoded also encode field values automatically (using + for spaces instead of %20).

However, when you build URLs programmatically in JavaScript or server-side code, you are responsible for encoding values correctly. Forgetting to encode can lead to broken URLs, security vulnerabilities (such as open redirects), or incorrect data being sent to APIs.

encodeURI vs. encodeURIComponent

JavaScript provides two built-in functions for URL encoding, and choosing the wrong one is a very common mistake:

• encodeURI() encodes a full URI. It does not encode characters that are valid in a URL structure, such as :, /, ?, and &. Use it when you have a complete URL that just needs non-ASCII characters encoded.
• encodeURIComponent() encodes a single value that will be placed into a URL. It encodes everything except A-Z a-z 0-9 - _ . ~ ! ' ( ) *. Use it when encoding query parameters, path segments, or any individual component.

The rule of thumb: if you are encoding a piece of data to put into a URL, use encodeURIComponent(). If you are encoding an entire URL that might contain Unicode, use encodeURI(). Getting this wrong is one of the most frequent sources of URL-related bugs.

Common Pitfalls

• Double encoding. If you encode a value and then encode the entire URL, the percent signs themselves get encoded (%20 becomes %2520). Always encode once at the right level.
• Spaces as + vs. %20. Form encoding uses + for spaces, but standard URL encoding uses %20. Most servers accept both in query strings, but be aware of the difference.
• Not encoding path segments. File names and directory names in URLs need encoding too, not just query parameters.
• Forgetting to decode. When reading values from URL parameters, remember to decode them before using the data. In JavaScript, use decodeURIComponent(). The URLSearchParams API handles this automatically.

The Modern Approach: URLSearchParams

Instead of manually calling encodeURIComponent() on each parameter, use the URLSearchParams API. It handles encoding and decoding automatically, supports iteration, and produces properly formatted query strings. Combined with the URL constructor, it is the safest and most readable way to build URLs in JavaScript.