Separate structure from data
A URL query is often written after a question mark as key=value pairs separated by ampersands. Those delimiters have structural meaning. If the value itself contains an ampersand, it must be represented within the value rather than mistaken for another pair. A component encoder prepares one piece of data; a query builder takes keys and values and joins the entire structure. These are two different levels of work. Do not pass a completed query through a component encoder or its question mark, equals signs and ampersands will become data. Conversely, do not paste raw untrusted values between separators and hope that the browser guesses the intended boundary.
A worked query with repeated keys
Suppose a search screen needs q equal to red & blue and two tag values, a and b. Give the JSON-to-query tool the object with q as a string and tag as an array. Its form-style serialization produces q=red+%26+blue&tag=a&tag=b. The plus sign represents a space in this query convention, while %26 protects the ampersand inside the search phrase. Parsing the output with the matching tool yields q as red & blue and tag as an array of two strings. The repeat is intentional: tag=a&tag=b is not the same structure as a single value containing a comma. Try changing one tag in the embedded tool.
- Raw: q = red & blue; tag = a, b
- Query: q=red+%26+blue&tag=a&tag=b
- Parse: q is one phrase; tag has two values
Why a component can look different
The dedicated URL component encoder uses the component rules for one value. A space can appear as %20 there, while a URLSearchParams-style query serializer uses plus for a space. Both spellings may be valid in their respective contexts, but they are not necessarily identical strings. A literal plus in a form-style query must be escaped so it does not turn into a space during parsing. Encoding an already encoded percent sign gives %25, the familiar sign of accidental double encoding. Keep raw keys and values until the query builder handles them, or encode exactly one component before manual assembly. Avoid mixing both strategies on the same data.
Know what the round trip preserves
The MultiVerto query parser turns repeated keys into arrays. All query values arrive as strings, even if the JSON builder accepted a number or boolean before serialization. It does not restore a missing original numeric type. Empty arrays and nested objects do not have a direct representation in this simple key/value format, so the builder rejects them. Different APIs also choose different policies for empty values, duplicate keys and ordering. A round trip can therefore preserve useful pairs without preserving every detail of a richer JSON object. Check the actual API contract before deciding how arrays, absent fields and empty strings should appear.
Make a stable test case
Start with the target endpoint and write down each key and raw value separately. Build the query once and inspect the output for encoded reserved characters. Parse it back to confirm that the intended pairs survived, especially values containing ampersands, plus signs, percent signs and non-ASCII text. Test a repeated key if the server supports arrays, and confirm that the server interprets it the same way. Never put secrets in a query string merely because characters are encoded: URLs can be copied, logged and shared. MultiVerto computes the example locally, but the URL you eventually publish or send has its own visibility and retention rules.