URLs, Encoding, and Query Strings

Every URL (Uniform Resource Locator) has a defined structure governed by RFC 3986. Understanding this structure helps make sense of why encoding is necessary and where it applies.

Each component has its own rules about which characters are allowed unencoded. The rules differ between the path, query string, and fragment — which is why URL encoding can be confusing.

URLs can only contain a limited set of ASCII characters. The characters A-Z, a-z, 0-9, and a handful of special characters (-, _, ., ~) are "unreserved" — they can appear in URLs without any encoding.

Other ASCII characters like ?, &, =, /, and # are "reserved" — they have special meaning within the URL structure. If you want to pass a value that contains one of these characters (like a search query containing an ampersand), you must encode it so the server doesn't misinterpret it as a URL delimiter.

Non-ASCII characters — anything outside the basic ASCII range, including letters from non-Latin alphabets, emoji, and accented characters — must always be encoded because they're not part of the original URL specification.

Percent-encoding (also called URL encoding) represents unsafe characters using a percent sign followed by two hexadecimal digits. The hexadecimal value is the UTF-8 byte value of the character.

For example, the space character has the UTF-8 byte value of 32 decimal, which is 20 in hexadecimal — so a space becomes %20. The ampersand (&) has the byte value 38 decimal = 26 hexadecimal, so it becomes %26.

Notice that the Euro sign (€) encodes to three percent-encoded bytes (%E2%82%AC). This is because the Euro sign requires 3 bytes in UTF-8 encoding, so each byte gets its own %XX representation.

The + Confusion

In query strings specifically, a + sign is historically used to represent a space (inherited from HTML form encoding). So q=hello+world and q=hello%20world both mean "hello world" in query strings. However, + outside of query strings is not a space — it's a literal plus sign. This inconsistency causes bugs; using %20 for spaces is unambiguous in all contexts.

Query strings are the mechanism for passing parameters to a web server through the URL. They begin with ? and consist of key-value pairs separated by &.

Reading Query Parameters

In JavaScript, the URLSearchParams API provides a clean way to parse and manipulate query strings:

const params = new URLSearchParams(window.location.search);
const query = params.get('q');       // "USB cable" (already decoded)
const page = params.get('page');     // "2"
const sort = params.get('sort');     // "price_asc"

// Setting parameters
params.set('page', '3');
const newUrl = '?' + params.toString();
// Automatically encodes values properly

URLSearchParams handles all the encoding and decoding automatically — you work with the decoded values and it handles the URL-safe representation.

JavaScript provides three ways to encode URLs, and choosing the wrong one is a common source of bugs:

Rule of thumb: When building URLs programmatically, always encode individual parameter values with encodeURIComponent() or use the URLSearchParams API which handles encoding automatically.

Base64 is a binary-to-text encoding scheme that represents binary data using only printable ASCII characters. Despite the name, it's not technically URL encoding — but it's frequently used in web contexts and often confused with URL encoding.

Base64 works by taking groups of 3 bytes (24 bits) of binary data and encoding them as 4 ASCII characters from a 64-character alphabet consisting of letters (A-Z, a-z), digits (0-9), and + and /. The encoded output is always 33% larger than the input.

Common Uses of Base64

• Email attachments: MIME encoding uses Base64 to embed binary files in text-based email messages
• Data URLs: Embedding images directly in CSS or HTML using data:image/png;base64,...
• JSON web tokens (JWTs): JWT claims are Base64url-encoded (a URL-safe variant)
• API authentication: HTTP Basic Authentication sends credentials as Base64-encoded strings
• Storing binary data in text fields: Databases or APIs that only accept text strings can store binary via Base64

Base64 vs. Base64url

Standard Base64 uses + and / which are special characters in URLs. "Base64url" replaces these with - and _, making the encoded string safe to use in URLs without percent-encoding. JWTs use Base64url encoding specifically for this reason.