Introduction

Whether a space should become + or %20 depends on the encoding context, not on personal preference. The short rule is: %20 is the normal percent-encoded form of a space, while + is a special convention used mainly in application/x-www-form-urlencoded data such as traditional HTML form submission.

The Core Difference

A literal space character is not allowed as-is inside a URL. In standard percent encoding, a space becomes %20 because ASCII space is hexadecimal 20.

+ is different. It is not the generic percent-encoded form of a space. It is a form-encoding convention used when serializing key-value pairs in the same style as browser form submissions.

That is why these two are not interchangeable everywhere.

When to Use %20

Use %20 in normal URI components such as path segments and in general percent encoding:

from urllib.parse import quote

print(quote("file name.txt"))

Output:

file%20name.txt

This is the correct choice for path-like data. If a filename or route segment contains spaces, %20 is the safe representation.

When + Appears

+ is common when encoding form fields:

from urllib.parse import urlencode

print(urlencode({"name": "John Doe"}))

Output:

name=John+Doe

That output is correct for form-style query encoding. Browsers and many servers decode + as a space in that specific context.

Why Paths and Query Strings Differ

The confusion usually comes from mixing path encoding with form encoding. In a URL path, + is just a literal plus sign unless the application treats it specially. In form-style query strings, + is commonly interpreted as a space.

So these two examples are not equivalent in meaning:

• '/files/My%20Report.pdf'
• '/files/My+Report.pdf'

The first unambiguously represents a space. The second may represent a literal plus sign in the path.

JavaScript Example

JavaScript's encodeURIComponent uses %20, not +:

console.log(encodeURIComponent("John Doe"));

Output:

John%20Doe

If you need form-style encoding, you usually build it through URL search parameter APIs or form serialization rather than replacing %20 manually everywhere.

Practical Rule of Thumb

If you are encoding:

• a path or filename: use %20
• a generic URI component: use %20
• HTML form style data: + may appear as part of form encoding

That rule avoids most bugs without needing to memorize the full RFC history behind every encoding convention.

The easiest way to stay correct is to avoid hand-encoding entirely. Use APIs that know whether you are building a path segment, a query value, or a form body. Most encoding bugs come from applying one rule globally to every part of the URL instead of encoding each component according to its actual role.

That is especially important when literal plus signs can appear in the data, because a plus sign that should stay a plus is a different problem from a space that needs encoding.

Common Pitfalls

• Using + inside URL paths and expecting it to mean space everywhere.
• Assuming %20 and + are globally interchangeable.
• Manually concatenating query strings instead of using encoding helpers.
• Encoding the entire URL at once when only components should be encoded.
• Forgetting that a literal plus sign may need encoding too.

Summary

• '%20 is the standard percent-encoded representation of a space.'
• '+ is mainly a form-encoding convention.'
• Use %20 for path segments and general URI components.
• Expect + mostly in application/x-www-form-urlencoded data.
• Encode URL components with library helpers instead of guessing.