Skip to content

Debug URL query parameters: spaces, repeated keys and relative paths

Reproduce query-string bugs caused by plus signs, duplicate keys, double encoding and relative URL resolution before changing your API client.

By DevToolPlace · Published October 5, 2026 · 2 min read

Start with the exact request URL

Inspect the URL actually sent in the browser network panel, including the query string. Compare that with the raw value supplied to your request builder. A value can change at several stages: form submission, component encoding, URL assembly, redirects and server parsing. Redact passwords and tokens before sharing a request URL. The URL inspector parses a string without making a request, so it is useful for examining the construction step separately from the endpoint.

A plus sign and a space are not always the same value

Query parsing with URLSearchParams treats a plus sign as a space. If you mean a literal plus, construct the query through URLSearchParams rather than interpolating the value yourself. This matters for phone numbers, mathematical expressions and opaque strings. Path segments follow different rules, so do not assume the query behavior applies to the pathname.

const params = new URLSearchParams();
params.set('q', 'C++');
console.log(params.toString()); // q=C%2B%2B
console.log(new URLSearchParams('q=C++').get('q')); // C  

Keep repeated keys until you decide what they mean

A request with tag=php&tag=json contains two values for the same key. In JavaScript, use getAll to read both. Converting entries into a plain object collapses repeated keys. Backend frameworks may interpret repeated keys differently, or expect bracket syntax for an array. Test the real endpoint and its schema instead of assuming that one query representation works across every server.

const params = new URLSearchParams('tag=php&tag=json');
params.getAll('tag'); // ['php', 'json']
Object.fromEntries(params); // { tag: 'json' }

Resolve a relative path against the correct base

An address without a leading slash resolves relative to the base directory; an address with a leading slash resolves from the origin root. A base ending in /app differs from one ending in /app/. These differences often explain why a fetch call works on the homepage but fails after navigating to a nested route. Inspect the resolved URL before diagnosing CORS or changing the server.

new URL('items', 'https://example.com/app/').href;
// https://example.com/app/items
new URL('/items', 'https://example.com/app/').href;
// https://example.com/items

Verify there is exactly one encoding layer

If a value is encoded before it is supplied to URLSearchParams, percent signs can themselves be encoded. A slash encoded as %2F can become %252F after a second pass. Keep raw values until the query builder serializes them. Add tests for spaces, plus signs, Unicode, repeated keys and empty values. Successful parsing does not prove the destination is safe or that the API accepts the resulting parameter names.

Reference documentation

Try the related tools with sample data

Found an error or a missing edge case? Send a reproducible example.