How to Build URL Query Parameters Without Breaking Values

When a URL works for a simple search term but fails for a name, an email address, a plus sign, or a repeated filter, the problem is often how the query string was assembled. The reliable approach is to treat query parameters as name-and-value data first, then let a URL-aware API serialize that data for the URL.

This guide answers a practical question: how do you build a URL with query parameters without changing the value that the receiving application is meant to read?

Encode parameter components, not the whole URL

A URL query begins after ? and is commonly made up of name/value pairs separated by &, such as q=tea&sort=recent. The URL Standard defines URL parsing and serialization, including application/x-www-form-urlencoded processing for query data. 1 2

The important boundary is the individual parameter name and value. The delimiters that give the query its structure—?, &, and =—must remain structural characters. Text that belongs inside a name or value must be serialized so it cannot accidentally become structure.

For example, this intended data:

q = tea & biscuits
page = 2

should become a query in which the ampersand inside the search text is encoded, rather than a second unintended parameter:

?q=tea+%26+biscuits&page=2

Do not run a generic encoder over an already-complete URL. Encoding the whole string can turn the separators into data and change https://example.com/search?q=... into something the URL parser no longer recognizes as that URL. Start with the base URL, add parameters through the platform’s URL or query-parameter API, and serialize once at the end.

The plus sign is a common source of silent changes

In application/x-www-form-urlencoded query processing, a literal + in the input is interpreted as a space. A literal plus sign therefore needs encoding when it is data, while a space may serialize as +. The URL Standard’s percent-decoding rules specify this replacement before percent decoding. 1

That distinction matters for values such as an email-style alias or a search expression:

Input value:  dev+alerts@example.com
Serialized query value: dev%2Balerts%40example.com

If a server expects a query parameter and receives dev+alerts@example.com unescaped, form-style parsing may give it dev alerts@example.com instead. Do not fix this by manually replacing every + after building a URL; provide the original value to a query-parameter API and inspect the resulting URL.

Preserve repeated keys and empty values deliberately

Query strings are not always a one-key, one-value dictionary. Some applications use repeated keys for multiple selected values:

tag=security&tag=networking

Other applications distinguish between an empty value (filter=), a present key without an equals sign (filter), and an absent key. The URL Standard represents query data as an ordered list of name/value tuples, and its form-urlencoded parser preserves duplicate names as separate entries. 1

Whether an API assigns different business meaning to those forms is its own contract. Before choosing a client-side representation, check the receiving endpoint’s documentation and test a harmless example. Do not collapse repeated keys into a comma-separated string or delete empty values unless that endpoint explicitly specifies that convention.

Avoid double encoding

Double encoding happens when text that is already serialized for a URL is passed through an encoder again. A percent sign is then encoded as %25, changing an already encoded ampersand from %26 to %2526.

For example:

Original value:          tea & biscuits
Encoded once:            tea+%26+biscuits
Encoded a second time:   tea%2B%2526%2Bbiscuits

The second result is not an alternative spelling of the first. It represents different characters. Keep raw application values and serialized URL text in separate variables or fields, label them clearly, and encode only at the point where the URL is constructed.

This also applies when copying a URL from a log or browser address bar. First determine whether the value you have is raw text or an already serialized component. Decode and re-encode only when the protocol requires a transformation, not just because percent signs look unfamiliar.

A dependable construction workflow

Use this sequence for links, API requests, redirects, and support reproductions:

1. Keep the base URL separate from the parameter data.
2. Store each intended name and value as ordinary text, without manually adding % escapes.
3. Use the URL-handling API in the language or platform that will send the request to append parameters.
4. Preserve duplicate keys in their required order and make a deliberate decision about empty values.
5. Inspect the final serialized URL, then test the receiving endpoint with a non-sensitive value that includes a space, &, +, and a non-ASCII character if the endpoint supports it.
6. Log or share only the redacted form of URLs that can contain tokens, email addresses, search terms, or other sensitive data.

The yukt.tools homepage lists URL encoding among its online utilities. A utility can help you inspect a non-sensitive sample, but it cannot tell you whether a particular service expects repeated keys, a comma-separated list, or a specific empty-value convention. The receiving service’s documented request format is the authority.

Frequently asked questions

Should I use %20 or + for a space in a query parameter?

Both forms can appear in URL-related contexts, but application/x-www-form-urlencoded serialization uses + for a space. Use the URL library or API required by the protocol instead of choosing based on appearance; it will apply the relevant serialization rules. 2

Why did an ampersand split my query value into another parameter?

An ampersand is a query-pair separator. If it is part of a value, it must be serialized as data—for example, %26 in form-style query serialization—before the complete query string is assembled. Building parameters through a URL API avoids treating the value’s ampersand as structure. 1

Is URL encoding a way to protect a secret in a link?

No. URL encoding changes how text is represented; it does not encrypt or hide it. Anyone who can see the URL can decode its parameters. Avoid placing secrets in URLs where possible, and follow the service’s security guidance for credentials and tokens.

Sources and research

1. WHATWG URL Standard: application/x-www-form-urlencoded parsing — primary specification for parsing query tuples, duplicate names, percent decoding, and plus-to-space handling, accessed 2026-10-02.
2. WHATWG URL Standard: URLSearchParams stringification behavior — primary specification for serializing query parameters, accessed 2026-10-02.