URL Encoding Spaces: %20 vs + — Which Is Correct?

A space can appear in a URL as either %20 or +, and both show up regularly in the wild. Most of the time either works — but they come from different standards, are produced by different functions, and mix badly if you're not careful about which one you're generating and which one the server expects.

%20: The RFC 3986 Standard

%20 is how the space character (Unicode code point U+0020, hex value 20) is represented in standard URI percent-encoding as defined by RFC 3986. It's the correct encoding for any part of a URL: query strings, path segments, fragment identifiers.

Functions that produce %20:

• JavaScript: encodeURIComponent(' ') → %20
• Python: urllib.parse.quote(' ') → %20
• C#: Uri.EscapeDataString(' ') → %20
• PHP: rawurlencode(' ') → %20
• curl: curl --data-urlencode → %20

+: HTML Form Encoding

+ as a space placeholder comes from the application/x-www-form-urlencoded media type — the format browsers use when submitting HTML forms. It's a historical shorthand, not part of the core URI spec.

Functions that produce + for spaces:

• JavaScript: new URLSearchParams({q: 'hello world'}).toString() → q=hello+world
• Python: urllib.parse.urlencode({'q': 'hello world'}) → q=hello+world
• Python: urllib.parse.quote_plus(' ') → +
• PHP: urlencode(' ') → +
• Java: URLEncoder.encode(' ', UTF_8) → +

The + is only valid in query strings — not in URL paths or fragment identifiers, where a literal + character is allowed unencoded.

Sell Custom Apparel — We Handle Printing & Free Shipping

Which Should You Use?

For API query parameters: both %20 and + are accepted by most web servers and frameworks. However, %20 is the safer and more correct choice for modern API work — it's unambiguous and follows the URI spec.

For HTML form submissions: browsers generate + automatically. You don't choose this — the browser handles it when a form is submitted with method="GET".

For URL paths: always use %20. A + in a path is a literal plus sign, not a space — servers won't decode it as a space.

The danger zone: mixing encoding sources. If your frontend generates + (URLSearchParams) and your backend decodes with a library that doesn't handle + as space, you'll get a literal + in the decoded value.

Decoding %20 and + Correctly

When decoding incoming query strings:

• To decode + as space: use decodeURIComponent(str.replace(/+/g, ' ')) in JavaScript, or urllib.parse.unquote_plus() in Python
• To decode only %20: use decodeURIComponent() directly — it doesn't convert +

Most web frameworks handle this automatically based on the Content-Type header. The issue appears when you mix form encoding and URI encoding without being explicit about which convention you're using.

To quickly decode a string and see which format it's using, paste it into the Mongoose URL Encoder decoder.

Frequently Asked Questions

If both work in query strings, why does it matter which I use?

In practice, most servers handle both. But if your server explicitly expects one format and receives the other, or if you're processing encoded strings in a pipeline where different layers make different assumptions, you'll get bugs. Using %20 consistently avoids the ambiguity.

My URL shows spaces as + in the browser address bar. Is that wrong?

No. Browsers commonly display query strings with + for spaces — it's valid for query strings. The server will decode + as space correctly. This is normal behavior from HTML form submissions.

Does %20 work in the query string or only in the path?

%20 works everywhere in a URL — path segments, query string values, fragment identifiers. + only works as a space substitute in query strings (and only when the receiver is set up to decode it that way).

What encodes a literal + sign if + means space in form encoding?

A literal + character is encoded as %2B in form encoding (and in standard percent-encoding). So if your value is "C++", it would encode as "C%2B%2B". This is one reason %20 for spaces is less confusing — + has its own meaning as a character.