b2KIT

Query String Builder

Build URL query strings from key-value pairs with encoding, sorting, and duplicate key handling options.

Tested tool guide Tested browser tools Checked August 16, 2026

What Query String Builder does, with a checked example

Type a key and a value on each row and this tool serializes them into a single URL query string, with toggles for percent-encoding, key sorting, and duplicate keys. Pairs are joined with &, keys and values with =. The output is only the query portion - you add the ? prefix and the page or endpoint yourself. The most common surprise is that characters with meaning in a URL (spaces, &, =, #, non-ASCII text) come out percent-encoded, so the resulting string can look nothing like what you typed.

Worked example

A concrete input and expected output from the current implementation.

Input

q: hello world
lang: en-US
page: 2

Expected output

q=hello%20world&lang=en-US&page=2

Each row becomes key=value and rows are joined with &. The space in 'hello world' is percent-encoded as %20 because spaces are not allowed raw in a query string; letters, digits, and the hyphen in en-US are unreserved and pass through unchanged. With key sorting enabled the pairs reorder to lang=en-US&page=2&q=hello%20world.

How the result is produced

1

Rows to pairs

Each row becomes one key=value pair, and pairs are joined with & in the order the rows appear unless sorting is on. An empty value serializes as key= with nothing after the equals sign. Because &, =, and # inside a value would be misread as structure, the tool offers encoding for exactly those characters.

2

Encoding, sorting, duplicates

Percent-encoding follows the URL unreserved set: letters, digits, and - . _ ~ stay as-is, while spaces, punctuation, and non-ASCII characters become UTF-8 percent-sequences such as %20 and %C3%A9. Sorting compares keys in code-point order, so uppercase keys sort before lowercase. Duplicate keys either repeat as separate pairs or collapse to the first or last occurrence, per the selected mode.

Good uses

  • Debug an API call: build the exact parameter string you intend to send and inspect the encoded form before pasting it into curl, a script, or a browser address bar.
  • Sanity-check a hand-written query: drop a value containing spaces, &, or non-ASCII text into a row to see what the wire form really is, instead of assuming your raw text survives.
  • Assemble a pre-filled search or filter link with several parameters in one go, with pairs sorted by key so the result is readable and diff-friendly.

Limits and checks

  • The output is encoded text, not your original values: %20 is a space, %C3%A9 is an é, and %26 is an &. If you paste the built string into a plain-text field expecting to see the values, you get the escaped forms.
  • There is no single canonical encoding. Form submissions typically use + for spaces while URIs use %20, and a few servers treat them differently. The builder's output is one convention, so confirm it matches what the receiving endpoint expects.
  • Only the query is produced - no ? and no base URL - so the string is not a complete, navigable URL by itself. And if you reorder or dedupe, remember that many servers read repeated keys as arrays or honor only the first occurrence, regardless of what the string shows.

Common questions

Why does my value come out as %C3%A9 when I typed é?

Because a query string on the wire is ASCII text. Non-ASCII characters are encoded as their UTF-8 bytes with percent prefixes: é is two bytes, C3 A9, hence %C3%A9. A space becomes %20. This is not a bug, and most receivers decode it back automatically. Leave encoding on unless the target endpoint is known to expect raw text.

If I type the same key twice, which value wins?

With duplicate handling set to keep, both pairs survive, as in tag=a&tag=b, which many frameworks parse into an array. With deduplication, either the first or the last occurrence is kept, depending on the mode you pick. The builder can only guarantee what the string contains - how the server resolves repeated keys is up to it.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools