URL Encoding explained

URLs have syntax rules. Characters such as spaces, question marks, ampersands, equals signs, hashes, and slashes can have special meaning depending on where they appear. URL encoding, also called percent encoding, lets a value include those characters without confusing the browser, server, proxy, or router that reads the URL.

For example, a space may become %20, and an ampersand inside a parameter value may become %26. Without encoding, the ampersand could be interpreted as the separator between query parameters. Encoding keeps the value intact while still allowing the full URL to be parsed correctly.

A full URL contains different parts: scheme, host, path, query string, and fragment. Encoding rules depend on the part you are editing. A slash in a path usually separates path segments, but a slash inside a query parameter value may be data. That is why developers often encode individual components instead of encoding an entire URL blindly.

In JavaScript terms, encodeURIComponent is usually safer for a single query value because it escapes characters that would otherwise affect query parsing. encodeURI is intended for a full URI and leaves some syntax characters alone. Mixing these functions is a common source of redirect bugs and broken callback URLs.

URL encoding appears in login redirects, OAuth callback URLs, tracking links, search filters, deep links, webhooks, and API clients. A redirect parameter may contain another URL, which means it must be encoded before it is added to the outer URL. Query filters can also contain JSON-like values, spaces, dates, or symbols that need safe transport.

When a URL fails, decoding helps reveal what the server actually receives. A value such as redirect=%2Ftools%2Fjson-formatter decodes to redirect=/tools/json-formatter. Once readable, it is easier to see whether the value was encoded once, encoded twice, or not encoded at all.

Double encoding happens when an already encoded value is encoded again. The percent sign itself becomes %25, so %2F turns into %252F. Servers then receive a value that still looks encoded after one decode pass. This often appears in redirect systems, nested query strings, and integrations where both client and backend encode the same value.

Broken percent sequences are another issue. A percent sign must be followed by valid hexadecimal characters. If a copied URL contains a raw percent sign from a label or user input, decoding may fail. Treat decoding errors as useful signals: they often point to the exact place where the URL stopped being a valid encoded component.

Start by separating the full URL into its parts. Identify the exact query parameter or path segment that looks wrong. Decode only that component, then check whether the decoded value is what the application expected. If the decoded value is another URL, inspect it separately so you do not confuse inner and outer query strings.

After fixing the value, encode it at the boundary where it becomes part of a URL. Do not encode the same value in multiple layers unless each layer owns a different URL component. This keeps links readable during debugging and prevents hard-to-find bugs in redirects, API requests, and shared links.

Do not decode an entire production URL, edit it as plain text, and paste it back without re-encoding the correct components. That often creates links that work for one simple case but break when a value contains spaces, ampersands, or another nested URL. Keep the structure clear: parse the URL, edit the value, then encode only the value that belongs in that location.

Do not rely on browser address bars as your only test. Browsers may normalize or display URLs in a friendlier way than the raw request your backend receives. When debugging an API call, inspect the actual request URL from the network panel, logs, or API client. That raw value is the one your server router and query parser must handle.

If a link is generated by code, add tests for values that contain spaces, symbols, Unicode characters, and nested URLs. These cases expose encoding mistakes much earlier than manual testing with simple words. A URL that only works with safe characters is usually one copy-paste away from breaking in a real login, search, filter, or redirect workflow.

Keep at least one encoded example in your documentation so future maintainers can compare real output with the intended format.