Query strings look simple — a few key=value pairs joined by & — but the encoding rules around them have enough edge cases to trip up even experienced developers. Here are the ones that come up repeatedly.
The + vs %20 trap
A space can legitimately be represented two different ways depending on context: as %20 (general percent-encoding, per RFC 3986) or as + (specific to application/x-www-form-urlencoded, the format HTML forms use). These are genuinely different conventions, not interchangeable — a + in a query string that came from a form submission means space, but a literal + character in arbitrary encoded data means a literal plus sign. Decoding with the wrong assumption silently produces wrong values instead of an error, which makes this bug hard to notice.
Double-encoding
Original: café
Encoded once: caf%C3%A9
Encoded twice: caf%25C3%25A9 ← the % itself got re-encoded to %25This happens when a value gets percent-encoded, then passed through an encoding step a second time somewhere else in the pipeline — a common cause is a framework or library that automatically encodes URL parameters, applied to a value you'd already encoded by hand. The fix is to encode exactly once, at the point where the value is actually inserted into the URL, and nowhere else.
Encoding an already-assembled URL by mistake
Running an entire URL through a value-encoder (like encodeURIComponent) rather than a whole-URL encoder mangles its own structure — the /, ?, and & characters that are supposed to remain structural get encoded along with everything else, breaking the URL entirely. Our URL Encoder is deliberately scoped to encoding a single value (a query parameter, a path segment) — not a full pre-built URL — since that's the far more common real need, and it avoids exactly this mistake by being explicit about scope.
Reserved characters that need encoding even though they look "safe"
Characters like &, =, ?, and # have structural meaning in a URL. If a value you're inserting into a query parameter happens to contain one of these literally — an email address containing +, a search term containing & — it must be percent-encoded or it'll be misread as part of the URL's own syntax rather than as data. This is the most common cause of a query parameter silently truncating at the wrong character.
Array and nested-object query parameters have no single standard
Encoding a single string value is well-specified. Encoding a list or nested object into a query string is not — different frameworks use different conventions (tags=a&tags=b, tags[]=a&tags[]=b, or tags=a,b). There's no universally correct choice here; the right format is whatever the receiving server actually expects, which is worth confirming rather than assuming.