URL Encoding for Spaces: %20 or Plus?

A space in URL data usually becomes %20, but form-style query serialization represents it as +. Both can be correct. The right output depends on the destination: use percent encoding for an individual URI component, and use the plus convention only when the receiving workflow expects application/x-www-form-urlencoded data.

The ClockTools URL Encoder makes that context explicit with URI Component, Full URL, and Form Data profiles. Paste green tea, switch profiles, and compare the output before changing application code.

Start with the destination

Do not ask “Which symbol always means space?” Ask which parser will receive the value.

For a path segment, fragment value, or individual query value, percent encoding is the dependable representation. The space character's UTF-8 byte is hexadecimal 20, so its percent-encoded triplet is %20.

For HTML form-style data, the serialization convention uses + for spaces and percent-encodes a literal plus as %2B. The WHATWG URL Standard defines this form-urlencoded behavior separately from general URL parsing.

The RFC 3986 URI syntax defines a percent-encoded octet as % followed by two hexadecimal digits. It also distinguishes reserved delimiters from unreserved data characters. That distinction is the reason encoding a value is different from encoding an entire address.

The %20 versus plus decision table

The last row prevents a common bug. If the intended value is C++, sending C++ through a form decoder may produce C . Encode each literal plus as %2B before form parsing.

Four reproducible ClockTools tests

We ran four small inputs through the current tool implementation. Its URI Component profile uses JavaScript encodeURIComponent. Form Data applies the same component encoding and then replaces %20 with +. Full URL uses encodeURI, which preserves URL structure.

These are deterministic transformation results, not search-ranking evidence. You can reproduce them locally in the browser. The page updates output immediately, reports percent escapes and byte counts, and does not need to send the input to a server for the conversion.

Use the URL Decoder to run the inverse check. Decode green%20tea under the component profile and green+tea under Form Data. The decoder warns when a plus appears under a non-form profile because the intended meaning is ambiguous.

What does component encoding protect?

A URL uses punctuation as grammar. In a query string, & can begin another parameter and = separates a name from a value. # begins a fragment. ? begins a query. If one of those characters belongs inside user data, leaving it raw can change the structure.

Consider the value timer & alarm. Component encoding produces timer%20%26%20alarm. The ampersand becomes %26, so a parser receives one value instead of interpreting alarm as a new parameter.

Encoding is representation, not validation or encryption. A percent-encoded redirect can still point to an unapproved host after decoding. An encoded script is still untrusted input. Validate allowed schemes, hosts, parameter names, and business rules after parsing. Avoid putting passwords, tokens, or other secrets in URLs because addresses can appear in history, logs, analytics, screenshots, and referrer data.

When you need to compare a before-and-after query string, the Text Diff Checker makes each changed escape visible. That is more reliable than scanning a long callback URL for one missing %25.

Why does double encoding create %2520?

Double encoding happens when already encoded text is treated as raw data and encoded again.

Start with one space:

```text

space -> %20

```

Encode %20 as a new component. The percent sign becomes %25, while the digits remain literal:

```text

%20 -> %2520

```

One decode changes %2520 back to %20. A second decode changes %20 to a space. If your application expects one decoding pass but receives a double-encoded value, the user may see %20 instead of a blank.

The fix is not to decode repeatedly until the text looks right. Repeated decoding can change deliberately encoded delimiters and create security problems. Identify the ownership boundary: exactly one layer should encode the component, and exactly one corresponding layer should decode it.

A space-mismatch debugging path

Use this path when one system sends %20 and another displays +, %2520, or a literal blank.

1. Capture the raw value before any framework parser changes it.

2. Identify whether the field is a path segment, query component, complete URL, or form body.

3. Record the expected decoded value, including literal plus signs.

4. Reproduce the same input in the matching ClockTools profile.

5. Decode once with the receiving profile.

6. Compare the result with the expected value.

7. Search the application flow for a second encoder or decoder if %25 appears unexpectedly.

This debugging path is intentionally narrow. It separates data context from guesswork, and every step has a visible input and output.

When should you encode a full URL?

Use the Full URL profile only when you want the address to remain an address. It preserves structural punctuation such as the scheme colon, slashes, question mark, equals sign, ampersand, and fragment marker while encoding characters such as spaces.

Use URI Component when a complete URL is itself nested inside another parameter. For example, a callback address placed in redirect= is data from the outer URL's perspective. Encoding the nested address as one component prevents its ? and & from joining the outer query.

Do not repeatedly pass an address through different profiles hoping for a universally safe string. Write the boundary explicitly:

```text

outer URL structure + encodeURIComponent(inner callback URL)

```

The receiving application should parse the outer URL, extract the callback component, decode it once, parse the resulting inner URL, and validate the destination. Encoding keeps syntax intact; validation decides whether the destination is allowed.