URL encoding, also called percent encoding, is the process of converting characters that are not permitted or have special meaning in URLs into a safe format that can be transmitted across the internet without ambiguity or corruption. When a character cannot appear directly in a URL, because it is reserved for a specific structural purpose, because it falls outside the ASCII character set, or because it has no defined URL representation, URL encoding replaces it with a percent sign followed by the two-digit hexadecimal code representing the character’s value in the ASCII or UTF-8 encoding scheme.

A space character, which cannot appear in a URL because it is not a valid URL character, is encoded as %20. The encoded URL https://example.com/search?q=redirect%20management contains an encoded space between redirect and management. The at sign, @: which has special meaning in URL authority components is encoded as %40 when it appears in a context where it should be treated as a literal character rather than as an authority delimiter. The forward slash, /: which is a URL path delimiter is encoded as %2F when it should be treated as a literal character in a path segment rather than as a path separator.

URL encoding is defined in RFC 3986, the same specification that defines URL syntax, and is a fundamental mechanism ensuring that URLs remain valid, unambiguous, and transmittable regardless of what characters the underlying resource names or parameter values contain. Without URL encoding a URL containing a space or an accented character would be syntactically invalid, breaking the URL parsing, transmission, and processing that the entire web depends on.

Why URL encoding is necessary

URLs can only contain a specific set of characters, characters outside this set must be encoded before they can appear in URLs. Understanding why this restriction exists clarifies why URL encoding is a necessity rather than an optional convention.

The ASCII restriction: the original URL specification was designed for the ASCII character set, 128 characters including letters, digits, and a small set of punctuation. URLs were intended to be composed entirely of ASCII characters, characters with codes 0-127. Non-ASCII characters, accented Latin characters like é, ü, ñ, non-Latin scripts like Chinese or Arabic characters, emoji, fall outside the original URL character set and cannot appear directly in URLs without encoding.

For non-ASCII characters URL encoding uses UTF-8 encoding, the multi-byte representation of the character in the Unicode standard, then percent-encodes each byte. The French character é, Unicode code point U+00E9, is represented in UTF-8 as the two bytes 0xC3 and 0xA9. URL encoding produces %C3%A9: the two bytes separately percent-encoded.

Reserved characters: certain ASCII characters have defined structural roles in URL syntax, they are reserved for specific purposes. The colon : separates the scheme from the authority. The double slash // introduces the authority. The forward slash / separates path segments. The question mark ? marks the start of the query string. The hash # marks the start of the fragment. The ampersand & separates query parameters. The equals sign = separates parameter keys from values.

When these reserved characters should appear as literal data, as part of a parameter value rather than as structural delimiters, they must be URL encoded. A URL parameter value that contains a & character, for example the company name Smith & Jones: must encode the & as %26 to prevent it from being parsed as a parameter separator. ?company=Smith%20%26%20Jones encodes both the spaces and the ampersand.

Unsafe characters: some characters are technically allowed in URLs but create problems in certain transmission contexts, spaces break URL parsing in many implementations, angle brackets < and > conflict with HTML markup, quotation marks conflict with HTML attribute delimiters. These unsafe characters are encoded to prevent transmission ambiguity even in contexts where they might technically appear.

URL encoding format and syntax

The percent encoding format is consistent, a percent sign followed by exactly two uppercase hexadecimal digits.

The encoding format: %XX where XX is the two-character uppercase hexadecimal representation of a byte value. %20 for a space, byte value 32 in decimal, 20 in hexadecimal. %2F for a forward slash, byte value 47, 2F in hex. %40 for an at sign, byte value 64, 40 in hex.

Lowercase hexadecimal is also valid, %2f is equivalent to %2F: but uppercase is the conventional form specified in RFC 3986. URL encoding is case-insensitive for the hexadecimal digits.

Multi-byte character encoding: non-ASCII characters that require multiple UTF-8 bytes are encoded as a sequence of percent-encoded bytes, one %XX pair per byte. The Japanese character 日, Unicode U+65E5, requires three UTF-8 bytes: 0xE6, 0x97, 0xA5. URL encoded: %E6%97%A5. The full encoding for a URL containing Japanese text may produce seemingly long strings of percent-encoded sequences.

The plus sign alternative: in query strings specifically a space is sometimes encoded as + rather than %20. q=redirect+management and q=redirect%20management both represent the search query “redirect management” in query strings. The + as space encoding is a form data encoding convention from HTML form submission, technically it is only valid in query string contexts, not in URL paths. Path segments use %20 exclusively for spaces.

Decoding: the reverse process, converting %XX sequences back to the characters they represent, is URL decoding. Servers URL-decode incoming request URLs before processing them. A request for https://example.com/search?q=redirect%20management is processed by the server as a search for “redirect management”, the %20 is decoded to a space before the query parameter is used.

Characters and their encodings

Different categories of characters have different URL encoding requirements.

Characters that never need encoding: unreserved characters may appear in URLs without encoding. The unreserved characters are uppercase and lowercase letters A-Z a-z, digits 0-9, and the four characters hyphen -, period ., underscore _, and tilde ~. These characters have no special meaning in URLs and can appear anywhere in a URL without ambiguity.

Characters that must always be encoded when used as data: reserved characters that serve structural roles in URLs must be encoded when they appear as literal data rather than as structural elements. These include the colon :, forward slash /, question mark ?, hash #, open and close brackets [ ], at sign @: used in the authority component, exclamation mark !, dollar sign $, ampersand &, single quote ', parentheses ( ), asterisk *, plus sign +, comma ,, semicolon ;, and equals sign =.

Space encoding: spaces must always be encoded in URLs. In paths and most URL components spaces are encoded as %20. In query string values spaces may be encoded as either %20 or +: though %20 is technically more correct and + is only appropriate in query string contexts.

Common special characters and their encodings:

• Space: %20 or + (in query strings)

• Exclamation mark !: %21

• Hash #: %23

• Dollar sign $: %24

• Ampersand &: %26

• Single quote ': %27

• Parentheses ( ): %28 %29

• Plus sign +: %2B

• Comma ,: %2C

• Forward slash /: %2F

• Colon :: %3A

• Semicolon ;: %3B

• Equals sign =: %3D

• Question mark ?: %3F

• At sign @: %40

• Open bracket [: %5B

• Close bracket ]: %5D

URL encoding in practice

Web browsers, frameworks, and tools handle URL encoding automatically in most contexts, but understanding how encoding works prevents debugging confusion when automatic encoding fails or produces unexpected results.

Browser automatic encoding: modern browsers automatically URL encode characters when a user types or pastes a URL containing non-URL-safe characters into the address bar. A user who types https://example.com/search?q=café into a Chrome address bar will see the browser encode the accented e, https://example.com/search?q=caf%C3%A9 in the actual HTTP request. The browser performs the encoding transparently, the user sees the decoded form in the address bar display.

HTML link encoding: HTML anchor tags can contain decoded URLs, <a href="https://example.com/search?q=café">: the browser encodes the URL when the link is followed. However it is good practice to encode URLs in HTML attributes rather than relying on browser encoding, <a href="https://example.com/search?q=caf%C3%A9">: for consistency across different HTML processing contexts.

Programming language encoding functions: all major programming languages provide URL encoding functions. JavaScript, encodeURIComponent() for encoding individual components, encodeURI() for encoding full URLs while preserving structural characters. Python, urllib.parse.quote() for encoding strings. PHP, urlencode() for form-data encoding, rawurlencode() for RFC 3986 encoding.

The distinction between component encoding and full URL encoding is important. encodeURIComponent() in JavaScript encodes all reserved characters, appropriate for encoding individual parameter values. encodeURI() encodes only characters that are invalid in a URL, it preserves structural characters like ?, &, =, and /: appropriate for encoding a complete URL that should retain its structure.

URL encoding and SEO

URL encoding intersects with SEO in specific ways, primarily through how search engines handle encoded URLs and how encoding affects URL readability signals.

Search engines handle encoded URLs correctly: Google and other major search engines decode URL-encoded characters when processing URLs. A URL containing %20 and a URL containing the actual space, which is technically invalid but browsers normalise, are treated as equivalent. Encoded non-ASCII characters in URL paths, %C3%A9 for é, are decoded and the decoded characters are used for indexing and ranking purposes.

IDN, Internationalised Domain Names: domain names with non-ASCII characters, münchen.de, 东京.jp: use Punycode encoding for DNS compatibility, xn--mnchen-3ya.de, xn--wgv71a309e.jp. URLs with IDN domains may display in the decoded native script form in browsers but are transmitted in Punycode. The URL encoding for path and query components is separate from Punycode encoding for domain names.

Canonical tag encoding consistency: canonical tags should use consistent URL encoding. If the same page is accessible at both an encoded URL, example.com/caf%C3%A9: and a decoded URL, example.com/café: the canonical tag should consistently specify one form as the canonical. Inconsistent encoding creates ambiguity about the intended canonical URL. Using consistently encoded URLs in canonical tags, particularly for non-ASCII paths, is the more reliable approach.

URL readability signals: URLs with human-readable unencoded text, /products/blue-widget: provide keyword signals through the readable words. URLs with heavily encoded content, /products/%62%6C%75%65%2D%77%69%64%67%65%74: encode the readable text in hex, providing no keyword signals from the URL itself. Use unencoded ASCII words in URL paths, encoding only characters that genuinely require encoding, to preserve URL readability and keyword signals.

URL encoding and redirects

URL encoding creates specific considerations in redirect management: redirect rules must correctly handle encoded and decoded URL variants.

Encoded vs decoded redirect source matching: redirect management platforms may match incoming request URLs in their encoded or decoded form. A redirect rule configured for /search?q=redirect management: with an unencoded space, may not match the actual request /search?q=redirect%20management: with an encoded space, depending on whether the platform decodes URLs before matching.

Testing redirect rules with both encoded and decoded variants of source URLs confirms whether the platform handles encoding correctly. If the platform matches decoded URLs the rule should be configured with decoded characters. If the platform matches encoded URLs the rule should be configured with encoded characters.

Percent-encoded characters in redirect rules: redirect rules for URLs containing special characters must use the correct encoding in rule patterns. A rule intended to match /products?category=shoes&colour=red must handle the & character correctly, the & in a URL should be %26 in a URL-encoded source pattern but & in a decoded-URL-match context. Understanding the redirect platform’s encoding handling is essential for correct rule configuration.

Redirect destination encoding: redirect destination URLs should use properly encoded forms. A redirect to https://example.com/résumé: with unencoded accented characters, may cause issues in some HTTP client implementations. A redirect to https://example.com/r%C3%A9sum%C3%A9: with properly encoded characters, is technically correct and universally compatible.

Double encoding: a common URL encoding error is double encoding, encoding an already-encoded URL, producing %2520 for a space instead of %20. This happens when URL encoding is applied twice, once explicitly and once automatically by a framework or library. %25 is the encoding for the % character itself, %2520 decodes to %20 rather than to a space. Double-encoded URLs cause redirect matching failures and deliver users to incorrect destinations.

Common URL encoding mistakes

Not encoding query parameter values: including special characters, particularly &, =, and #: in query parameter values without encoding them. A parameter value containing &: ?name=Smith&Jones: is parsed as two parameters: name=Smith and Jones (with no value). The correct encoding is ?name=Smith%26Jones: the & encoded as %26 is treated as a literal character in the value.

Encoding structural characters that should not be encoded: encoding the structural characters, /, ?, &, =: that define URL structure. https://example.com%2Fproducts%2Fblue-widget: with encoded slashes, is a URL where %2Fproducts%2Fblue-widget is part of the authority’s path, not a path with segments. The encoded slashes produce a different URL than the intended path-structured URL.

Double encoding: applying URL encoding to already-encoded URLs. Processing a URL through an encoding function when it already contains %20 sequences produces %2520: the % itself gets encoded. Always check whether a URL is already encoded before applying encoding.

Inconsistent encoding in canonical tags and redirects: using encoded URLs in some contexts and decoded URLs in others for the same resource. example.com/caf%C3%A9 in a canonical tag but example.com/café in an internal link, inconsistent encoding creates URL identity ambiguity. Use consistent encoding throughout, either always encoding non-ASCII characters or relying on browser normalisation consistently.