Context

Google Chrome currently encodes query string parameters with spaces using + instead of %20. Jira does not parse the + encoded space correctly when passed in the searchString parameter

Example URLs:

Working form (space encoded as %20):
jira/search?searchString=SPONMODS%20cleanup

Desired equivalent form (space encoded as +):
jira/search?searchString=SPONMODS+cleanup

Problem / Need

Many integrations, libraries, and tools that construct URLs follow the general URI percent-encoding rules and encode spaces as + rather than %20.

Today, Jira Cloud search functionality and/or the surrounding UI/redirect logic appear to be opinionated toward %20 in query parameters. This can lead to:

Confusion when manually crafting URLs, documentation examples, or deep links.

Inconsistent behavior between clients using URLEncoder (which produces %20) and clients or middleware that use plus encoding + .

Extra workarounds in scripts, browser tools, or third‑party integrations that must “normalize” URLs to + even though %20 is a valid encoding for spaces in URIs.

From a user/integrator perspective, both encodings are expected to be treated equivalently when parsing query parameters for search text.

Feature Request

Please enhance Jira Cloud’s search URL handling so that:

+ in query parameters (e.g. searchString=SPONMODS+cleanup) is reliably accepted and interpreted as a literal space, equivalent to %20.

This behavior is consistent across:

• The main issue navigator / search page (jira/search and related endpoints)
• Any redirect/landing flows that take a searchString or similar parameter
• Any documented or public search-related GET endpoints where users are likely to construct URLs manually or via integrations

The goal is not to change the existing behavior that already accepts %20, but to ensure that + is also fully supported and equivalent wherever a space is expected in a search term.

Why this matters

Standards alignment: + is used in multipart/form-data encoding which is sometimes used in URI encoding

Integrations & automations: Third‑party tools, scripts, and browser extensions frequently build query strings with +, and users expect these URLs to “just work” in Jira.

User experience: Users who are familiar with URL encoding often default to + when hand‑crafting URLs. Having Jira accept this encoding avoids surprising errors or unexpected search results.

Example use cases

Customer or admin copies/builds a Jira search URL in documentation, using + for spaces, and expects Jira to run the same search as when %20 is used.

Automation or external reporting scripts generate search or deep-link URLs into Jira using a generic multipart/form-data encoder (which emits +).

Browser tools and plugins that create direct links to Jira search use + for spaces and currently need Jira-specific workarounds.

Requested outcome

Jira Cloud search should robustly handle both + and %20 as encodings for spaces in search-related query parameters, with consistent behavior and documented expectations.

Ideally, this should be documented in public developer docs or user docs so app developers and admins can rely on it when constructing search URLs.

 

This is because the + encoding gets converted to 

issues/?jql=textfields%20~%20%22SPONMODS%2Bcleanup%22

but the desired result is

issues/?jql=project%20%3D%20SPONMODS%20AND%20text%20%7E%20cleanup&quickSearchQuery=SPONMODS%20cleanup

which is the result when %20 encoding is used