How to Handle Repeated Query Parameters

AIGClub Team

Repeated Query parameters are common in multi-select filters, checkbox values, batch IDs, and accidental UTM concatenation. The tricky part is that backend libraries and frameworks do not all use the same default behavior.

When a Query String repeats a key, debugging should preserve every value and its order first. Do not assume the last value wins; the target system may take the first value, take the last value, merge an array, or treat repeats as invalid.

Why repeated keys appear

  1. Multi-select filters, checkboxes, and batch resource IDs can produce same-name parameters. For ?tag=json&tag=url&empty=, preserve the two tag rows in order and keep empty as a present key with a blank value.
  2. Some systems use tags=a&tags=b for arrays, some use tags[]=a&tags[]=b, and others require comma-separated values.

Overwrite risk

If a script assigns grouped[key] without checking ownership, repeated values can be overwritten and names such as __proto__, constructor, or toString can collide with inherited properties. Preserve ordered rows first, then group into a Map or an own-key-safe object.

Recommended review flow

List every parameter in order first, then store repeated keys as arrays. After confirming the target system's rules, decide whether to use comma-separated text, [] keys, a single final value, or an explicit validation error.

Frequently asked questions

Does tag=a&tag=b always mean an array?
No. Many systems interpret it as an array, but some take only the first or last value. Check the receiving framework or API documentation.
Can repeated keys appear in signed URLs?
Yes, but the signing rules must define sorting, encoding, and duplicate-key behavior. Do not discard repeated values while debugging.
How should repeated parameters be exported to CSV?
Define the destination rule first. Arrays can become JSON strings, comma-separated text, or expanded rows, but they should not be overwritten silently.
Back to blog