A query string looks simple until two systems disagree about what it means. The serialized form is a sequence of key-value pairs, but repeated keys are legal and applications variously keep the first value, keep the last, build an array, or reject the request. This parser preserves every pair in source order rather than silently choosing a policy for you.
Form-style query encoding has another historical rule: a plus sign decodes to a space, while a literal plus must be percent-encoded. Keys and values are decoded independently, malformed percent escapes are rejected, and the canonical form shows how the parsed pairs serialize back through URLSearchParams.
Sensitive values in a query string deserve special attention because URLs spread. They appear in browser history, reverse-proxy logs, analytics, screenshots, and sometimes Referer headers. tryb warns on credential-shaped parameter names without displaying a fake claim that it knows whether the value is real.
Edge cases worth knowing
- Repeated keys
- a=1&a=2 is preserved as two ordered entries. The parser reports the ambiguity but does not guess how your framework resolves it.
- Plus signs
- q=hello+world becomes hello world under application/x-www-form-urlencoded rules; q=1%2B1 retains the literal plus.
- A single assignment
- One key=value pair is accepted at lower confidence because it can also be configuration syntax. A leading question mark or multiple pairs provide stronger evidence.
Common mistakes
- Converting parameters directly to an object and silently discarding repeated values.
- Treating plus as a literal character in form-encoded query data.
- Putting passwords, API keys, or bearer tokens in a URL where infrastructure can log them.
- Decoding the complete string before splitting it, which can turn encoded delimiters into structure too early.