URL encoding explained

URLs use characters such as ?, &, =, /, and # as syntax. When those same characters are part of a value, they need to be escaped so the URL parser reads them as data. URL encoding solves that by replacing characters with percent sequences.

For example, a space becomes %20 and an ampersand becomes %26. Without encoding, a value that contains an ampersand could accidentally split one query parameter into two.

A common mistake is encoding the wrong level. If you are building a query string, encode each parameter value, not the entire URL after it has already been assembled. Encoding a whole URL as a value is correct only when the full URL is nested inside another URL, such as a redirect_uri parameter.

Most application code should use URL and URLSearchParams APIs instead of manual string concatenation. Tools are helpful for debugging, but code should rely on structured URL builders when possible.

When debugging OAuth redirects, search filters, webhook callbacks, or tracking links, decode the relevant value first. The decoded value reveals whether the expected URL, search term, or JSON-like string was actually sent.

If a server receives a weird value with visible %2520 sequences, you may be looking at double encoding. The percent sign itself was encoded into %25.

URL encoding does not validate whether a redirect target is safe, whether a parameter should be trusted, or whether a request is authorized. It only changes representation. Applications still need validation, allowlists, and authorization checks.

For public URLs, keep encoded values readable where possible and avoid putting secrets in query strings. Query strings can appear in logs, browser history, analytics, and referrer headers.