URLs use reserved characters to separate components such as the scheme, host, path, query, and fragment. Percent-encoding lets a URL include bytes that would otherwise be unsafe or ambiguous.

Try individual values with the QuickToolsBox URL Encoder and Decoder. The tool is useful for checking query parameters and understanding copied links.

What percent-encoding looks like

A percent-encoded byte is written as % followed by two hexadecimal digits. For example:

  • A space can become %20
  • / is %2F when treated as data rather than a path separator
  • ? is %3F when treated as data rather than the beginning of a query
  • # is %23 when it should not start a fragment

The phrase blue sky can therefore be represented as blue%20sky.

Encode components, not blindly the entire URL

Suppose an application builds a search URL from a user-entered phrase. The safe pattern is to encode the parameter value and preserve the URL structure:

https://example.com/search?q=blue%20sky

Encoding the complete URL may also encode :, /, ?, and =, destroying the separators that give the URL its meaning. Most programming languages provide one function for an entire URI and another for an individual component. Choose the one that matches what you are building.

Spaces: %20 versus +

In a URL path, a space is normally represented as %20. In query strings produced using HTML form encoding, a space is often represented as +. A literal plus sign in such a query should be encoded as %2B.

This difference explains why replacing every space with a plus sign is not a general URL-encoding algorithm.

Unicode characters

Non-ASCII characters are first converted to bytes, normally with UTF-8, and then each required byte is percent-encoded. A single visible character may therefore become several %XX sequences.

Browsers often display international characters in a friendly form while sending an encoded representation. Both views may identify the same resource.

A reliable workflow

  1. Identify whether you are encoding a path segment, query value, fragment value, or full URL.
  2. Use UTF-8 unless the receiving system explicitly requires another encoding.
  3. Encode the component once.
  4. Build the final URL using the original structural separators.
  5. Decode and inspect the result during debugging.

Common mistakes

Double encoding

If %20 becomes %2520, the percent sign was encoded a second time. Double encoding commonly happens when both an application and a framework encode the same value.

Decoding too early

Security checks should operate on a clearly defined representation. Repeated or inconsistent decoding can allow two layers of an application to interpret the same input differently.

Treating a fragment as server data

The part after # is normally handled by the browser and is not included in the HTTP request to the server. Put server-side parameters in the path or query instead.

Encoding a slash that should remain structural

A slash separates path segments. Encode it only when the slash is part of the data inside one component and the receiving system supports that representation.

Frequently asked questions

Is URL encoding the same as HTML encoding?

No. URL encoding protects URL components. HTML encoding represents special characters inside HTML. The correct method depends on the output context.

Are hexadecimal letters case-sensitive?

The hexadecimal digits in percent-encoded bytes are case-insensitive, so %2f and %2F represent the same byte. Uppercase is often used for readability.

Should an already encoded value be encoded again?

Usually not. Track whether your application is working with raw or encoded values and encode once at the boundary where the URL is constructed.