A query string builder exists because hand-writing query strings is deceptively easy to get wrong. The separators are three characters — ?, &, and = — and every one of them also appears inside real values. An unencoded ampersand in a campaign name silently splits one parameter into two. An unencoded equals sign in a token truncates it. Neither failure produces an error; both produce data that is quietly wrong in every report downstream.
Arb Digital uses this builder when assembling tracking links, API test calls, and prefilled form URLs, because it encodes every key and value correctly, flags the two mistakes that cause most broken links — duplicate keys and empty values — and does it all in your browser with no request leaving the page.
What This Query String Builder Does
Enter parameters as key and value pairs, one per row, and the tool assembles them into a query string with correct percent-encoding applied to both sides of each pair. Add a base URL and it returns the complete link, replacing any query string the base already carried so you never end up with two question marks in one URL.
The result panel reports four things worth knowing before you ship a link: the encoded length of the query string, how many keys appear more than once, how many values are empty, and the total length of the finished URL. Duplicate keys and empty values are both legal, and both behave unpredictably across frameworks, so seeing the count before you send the link is the point.
A space-encoding toggle lets you choose between %20 and +. Both appear constantly in real query strings, and knowing which one your receiving system expects occasionally matters — signature verification and strict parsers being the usual cases.
How to Use It
- Set the base URL, or clear the field if you only want the query string itself to paste into existing code.
- Fill in the parameter rows. Type keys and values exactly as you want them received — raw, with spaces and punctuation intact. Encoding is applied automatically.
- Add or remove rows with the add button and the remove control on each row. Blank rows are ignored in the output.
- Choose the space encoding if the receiving system has a preference. When in doubt, leave it on percent encoding.
- Check the warnings for duplicate keys and empty values, then copy the finished URL.
The Formula / How It's Calculated
A query string is the part of a URL after the first ? and before any #. Its internal structure is a convention rather than a strict rule: pairs joined by &, each pair split on the first =. Nothing in the URL specification requires that shape, but every web framework in common use assumes it, and the WHATWG URL Standard defines the parsing and serialising rules browsers follow.
Encoding follows RFC 3986: characters outside the unreserved set — letters, digits, hyphen, period, underscore, and tilde — are replaced by a percent sign followed by two hexadecimal digits representing each UTF-8 byte. Non-ASCII characters are encoded per byte, so a single accented character becomes two percent-escapes and an emoji becomes four.
This tool encodes the reserved separators &, =, ?, #, and + inside both keys and values, which is what keeps a value containing those characters from being misread as structure. The encoded length shown in the results is the length after encoding, not before — a value with several spaces and accents can be noticeably longer once encoded, which matters when you are working against a length limit.
Why Plus and %20 Are Not Interchangeable Everywhere
Inside a query string, most servers decode + as a space. That behaviour comes from the application/x-www-form-urlencoded format used by HTML form submissions, and it has been inherited by nearly every query-string parser since. Inside a path, however, + is a literal plus sign and nothing else. A file named report+final.pdf in a path is not the same as one named report final.pdf, but the same two strings in a query string usually decode identically.
The practical consequence: never rely on + when the value might be verified rather than merely read. Signed URLs, webhook payload verification, and OAuth signature bases are all computed over the exact byte sequence of the query string. If one side encodes a space as %20 and the other recomputes the signature assuming +, the signatures differ and the request is rejected with an error that says nothing about spaces. Percent encoding is the conservative choice for anything that will be signed, hashed, or compared.
Duplicate Keys: Legal, Common, Unpredictable
Repeating a key is allowed. ?tag=blue&tag=green is a perfectly valid query string, and it is the standard way to express a list in a URL. What is not standard is how it is read. Some frameworks return the first value, some the last, some an array of both, and some throw the extras away silently. Two services in the same stack can disagree, which is how a filter appears to work in the application and not in the analytics that shadows it.
Deliberate repetition for a multi-value filter is fine as long as you know the receiving code expects it. Accidental repetition — usually caused by appending parameters to a URL that already had them — is a bug, and it is the case the duplicate counter in this tool exists to catch. If your builder shows duplicates you did not intend, the fix is upstream: replace the parameter rather than appending it.
Empty Values Versus Absent Keys
There are three distinct states a parameter can be in, and they are easy to conflate. ?ref=partner sends a key with a value. ?ref= sends a key with an empty string. Omitting ref entirely sends nothing. Validation code that tests only for the presence of a key will accept the empty-string case and then fail later when it tries to use the value.
This shows up most often in tracking links assembled by templates, where a variable that failed to populate leaves behind utm_content=. Analytics platforms then record an empty dimension value, which usually groups under a blank or "(not set)" label and quietly fragments the report. The empty-value counter here surfaces those before the link ships. Our UTM grader checks the same class of problem specifically for campaign links.
How Long Can a URL Actually Be?
No limit is defined in the URL standard itself, and modern browsers handle extremely long addresses. Real constraints come from the software in between. Many server configurations cap the request line at around eight kilobytes by default and return a 414 status when it is exceeded. Some corporate proxies and older appliances cut in much lower. Email clients and messaging apps wrap or truncate long links in ways that break them on click.
A practical working ceiling for a link that will be shared, emailed, or printed is a few hundred characters. If you are past that, the usual fix is to stop passing state in the URL: store it server-side behind a short identifier, or move the payload into a POST body. The full URL length figure in the results panel is there to make that decision visible while you are still building the link.
Ordering, Caching, and Canonical URLs
Parameter order is not semantically meaningful — ?a=1&b=2 and ?b=2&a=1 address the same resource. Caches and search engines, however, frequently treat them as different strings. A CDN keyed on the full URL will store two copies of an identical response. A crawler may treat both as separate URLs and split their signals unless a canonical tag points them at one version.
The fix is to be consistent: pick an order — alphabetical is easiest to enforce — and generate links the same way every time. Because this builder emits parameters in the order you list them, you can standardise on a row order once and reproduce it exactly for every link in a campaign. It also helps to strip parameters that do not change the response, such as internal tracking values, from the canonical version of a page.
Arrays, Nested Objects, and Framework Conventions
Query strings have no native support for structured data, so frameworks invented their own conventions. PHP and Rails use bracket notation, tags[]=blue&tags[]=green and user[name]=Sam. Some APIs use comma-separated values in a single parameter. Others repeat the bare key. None of these is more correct than the others, and none is understood universally.
Because this builder encodes keys as well as values, brackets are percent-encoded in the output, which is what the specification calls for and what nearly every framework decodes correctly on receipt. If a specific API documents that it requires literal unencoded brackets, that is a deviation on their side worth checking against their documentation before you assume the encoded form is broken.
Arb Digital builds tracking and attribution setups where parameters are consistent, encoded correctly, and mapped to the reports you actually read.
Paid Advertising Services Talk to Arb DigitalCommon Mistakes to Avoid
- Encoding the whole URL instead of the values. This turns the separators into data and produces a link nothing can route.
- Appending parameters to a URL that already has a query string with another
?rather than an&— everything after the second question mark becomes part of a value. - Leaving empty values in template-generated links. They look harmless and quietly create blank dimensions in reporting.
- Assuming duplicate keys resolve the way you expect. Confirm with the receiving system rather than with a guess.
- Putting secrets in a query string. URLs land in server logs, browser history, and referrer headers — use headers or a request body instead.
Related Free Tools From Arb Digital
Take a finished link apart again with the URL parser, encode or decode one value at a time with the URL encoder and decoder, assemble campaign links to a fixed convention with the UTM builder, generate clean path segments with the slug generator, and confirm what a link returns using the HTTP status code lookup. More sit in the free online tools hub.
Frequently Asked Questions
No. The query string is assembled in your browser with JavaScript. Nothing is uploaded or stored, so internal endpoints and test values are safe to enter.
Either works in most query strings, but percent encoding is safer. Anything that signs, hashes, or byte-compares the URL may treat the two forms as different values.
Yes, and it is the usual way to pass a list. How it is interpreted depends on the receiving framework, which may take the first value, the last value, or all of them as an array.
It is sent as a key with an empty string. Many validators treat that as present rather than missing, so it can pass a presence check and then fail when the value is used.
The URL standard sets no limit, but servers, proxies, and email clients apply their own. Many server defaults cap the request line around eight kilobytes and return a 414 status beyond that.
Not to the server logic in most cases, but caches and crawlers often treat different orders as different URLs. Generating parameters in a consistent order avoids duplicate cache entries.
There is no universal format. Repeating the key, using bracket notation, and comma-separating values are all common conventions, so follow whatever the receiving API documents.
Encoding rules here follow RFC 3986. Individual APIs occasionally document their own requirements, which take precedence for that service.
