If you've ever clicked a link and noticed the URL contains things like %20, %3D, or %26, you were looking at URL encoding in action. It looks confusing at first, but it's actually a straightforward system that solves a real problem: URLs are restricted to a specific set of characters, and percent encoding is how everything outside that set gets safely included.
For everyday users, URL encoding is mostly invisible - browsers handle encoding and decoding automatically. But for developers building APIs, handling form submissions, constructing redirect URLs, or debugging HTTP requests, understanding how percent encoding works and knowing when it's applied is essential knowledge. Getting it wrong is one of the more common sources of subtle bugs in web applications.
The URL Character Problem
A URL is made up of several components: scheme (https://), domain (example.com), path (/search), and query string (?q=something&page=1). The URL specification defines which characters are allowed in each component without encoding. Letters, digits, and a handful of symbols like hyphens, underscores, tildes, and periods are 'unreserved' characters that can appear anywhere. Other characters are 'reserved' - they have specific structural meaning in a URL.
The ampersand (&) separates parameters in a query string. The equals sign (=) separates parameter names from values. The question mark (?) separates the path from the query string. The slash (/) separates path components. If you try to include an ampersand inside a parameter value without encoding it, the URL parser will interpret it as the start of a new parameter rather than data.
Spaces aren't valid in URLs at all. Non-ASCII characters - accented letters, Chinese characters, Arabic script - also aren't valid in the raw URL format (though they're handled through a separate internationalization layer). All of these need to be encoded before they can safely appear in a URL.
How Percent Encoding Works
Percent encoding replaces a character with a percent sign followed by its two-digit hexadecimal ASCII code. A space has ASCII code 32, which is 20 in hexadecimal, so a space becomes %20. An ampersand has ASCII code 38, which is 26 in hexadecimal, so an ampersand in a value becomes %26. An equals sign is %3D.
For non-ASCII characters, the character is first converted to its UTF-8 byte sequence, and then each byte is percent-encoded. A single Chinese character might encode to three bytes, producing three percent-encoded values: something like %E4%B8%AD. This is why URLs containing non-English text look dramatically different from the original text - each character might expand to nine or more characters in the encoded form.
encodeURI vs encodeURIComponent: A Common Source of Bugs
JavaScript provides two built-in functions for URL encoding, and choosing the wrong one is a frequent source of bugs. encodeURI is designed to encode a complete URL. It doesn't encode characters that have structural meaning in URLs like /, ?, =, and &, because those characters are intentional parts of the URL structure. encodeURIComponent is designed to encode a URL component - a single parameter value or path segment. It encodes everything that's not an unreserved character, including /, ?, =, and &.
The mistake is using encodeURI when you should use encodeURIComponent. If you have a parameter value that contains an equals sign (maybe it's a math expression, or an encoded token, or a Base64 string), encodeURI will leave the equals sign unencoded. When the server receives the URL, it will misparse the parameter because the equals sign looks like a separator. encodeURIComponent handles this correctly.
The practical rule: when encoding a complete URL you've constructed yourself, use encodeURI. When encoding a single parameter value that will be concatenated into a URL, use encodeURIComponent. The latter is needed far more often in actual development work.
OAuth and Redirect URLs
OAuth flows require passing a redirect URL as a query parameter in the authorization request. Something like: https://auth.example.com/oauth/authorize?redirect_uri=https://myapp.com/callback&scope=read. The redirect_uri value itself is a URL containing :// and /. Without encoding, the slashes and colon in the redirect URL confuse the parameter parsing.
The redirect_uri value needs to be percent-encoded: redirect_uri=https%3A%2F%2Fmyapp.com%2Fcallback. This is a common implementation detail that trips up developers implementing OAuth for the first time. The outer URL uses its structural characters normally; the inner URL is percent-encoded because it's being used as a value, not a URL itself.
Form Submission and application/x-www-form-urlencoded
HTML forms submitted with the POST method use a body encoding called application/x-www-form-urlencoded. This uses similar percent encoding rules to URL query strings, with one difference: spaces are encoded as + rather than %20. This is the historical form encoding, predating the standard URL encoding specification.
This means that if you're reading form data on a server and a field value contains a + sign, you need to decode it as a space, not a literal plus. And if a form value legitimately contains a plus sign, it would have been encoded as %2B, not as +. This distinction causes occasional bugs when developers mix the decoding rules for form encoding and URL encoding.
Debugging with a URL Encoder and Decoder
An online URL encoder and decoder is useful for several practical debugging tasks. When an API request is returning unexpected results and you can't tell why, decoding the full URL often reveals a parameter that's not being interpreted the way you expected. When you're building redirect URLs for OAuth or other flows and need to verify that the encoding is correct, an encoder lets you test the encoding without writing code.
Reading server logs that contain encoded URLs is much easier when you can paste the URL into a decoder and see it in human-readable form. Comparing two similar URLs to find where they differ is also easier in decoded form.
Online Quick Tools provides a free URL encoder and decoder that handles both standard percent encoding and form encoding. Paste a URL to decode it, or paste a string to get the correctly encoded version - all in your browser with no account required.