URL Encoding Explained: What It Is and Why It Matters

If you have ever noticed %20 in a URL where you expected a space, or %2F where you expected a slash, you have encountered URL encoding. It is one of those foundational web concepts that most developers understand intuitively from experience but rarely fully understand: which leads to subtle bugs in API integrations, broken links, and query string parsing errors.

Why URLs need encoding

URLs are defined by RFC 3986, which specifies that they may only contain a specific set of characters: the unreserved characters (A-Z, a-z, 0-9, hyphen, underscore, period, tilde) and a set of reserved characters that have special meaning in URL structure (/, ?, #, &, =, :, etc.). Any other character, including spaces, accented letters, Chinese characters, emoji, and most punctuation, must be encoded before it can be placed in a URL.

The reserved characters present a subtler problem. A forward slash / is perfectly valid in a URL: it separates path segments. But if you want to include a literal forward slash as data in a URL (for example, as part of a search query), it needs to be encoded so the browser does not interpret it as a path separator. The encoding signals: this character is data, not URL structure.

How percent-encoding works

URL encoding is also called percent-encoding because its mechanism is to replace each unsafe byte with a percent sign followed by two hexadecimal digits representing the byte's value. A space has the ASCII value 32, which is 20 in hexadecimal: so a space becomes %20. An @ symbol has the ASCII value 64, which is 40 in hexadecimal: so @ becomes %40.

For characters outside the ASCII range (non-Latin letters, emoji, characters from non-Latin scripts), the character is first encoded as UTF-8, which may produce multiple bytes, and then each byte is percent-encoded. The Chinese character 中 is encoded as three bytes in UTF-8 (0xE4, 0xB8, 0xAD), producing the percent-encoded string %E4%B8%AD.

Common URL encoding mistakes

• •Encoding the entire URL instead of just the data portions: if you encode the slashes and colons in https://example.com/path, you break the URL structure. Only encode the values within query strings and path segments that contain special characters.
• •Double-encoding: encoding an already-encoded string. If %20 is encoded again, the % becomes %25, producing %2520 instead of a space. This causes values to arrive at the server with literal %20 in them instead of spaces.
• •Using + for spaces in path segments: the + character represents a space in application/x-www-form-urlencoded format (query strings from HTML forms), but not in path segments, where it is a literal + and spaces must be %20.
• •Not decoding before display: displaying URL-encoded strings in your UI without decoding them shows users %E2%80%99 instead of an apostrophe. Always decode user-facing strings after receiving them.
• •Inconsistent encoding in API integrations: if your system percent-encodes a query parameter and the receiving system decodes it twice, or not at all, you get mismatches. Agree on encoding conventions at integration design time.

URL encoding in JavaScript

JavaScript provides two main encoding functions. encodeURI() is designed for encoding a complete URL: it does not encode characters that are valid in URLs (including /, ?, #, &). encodeURIComponent() encodes everything except the unreserved characters, making it correct for encoding individual query parameter values or path segments. When in doubt, use encodeURIComponent() for data values and let your URL construction library handle the rest.