Crafting an API URL with several parameters that include spaces, accents, punctuation, or other special characters. Building a tracking or campaign link (UTM tags, analytics parameters) without typos in the encoded values. Constructing a deep link or share URL that has to survive being pasted into email, chat, or social media without corruption. Testing which array notation an API endpoint expects — a[]=1 , a=1&a=2 , or something else — by trying each variant. Debugging query-string issues by examining the exact encoded output and comparing it to what the server received. Generating OAuth, webhook signature, or signed-request strings where parameter order and exact encoding matter.

Add rows: Type a key name and value for each parameter you want. The tool accepts any text in either field. Mark repeats: If you want a key to appear multiple times (for arrays or multi-select fields), toggle the "multi" checkbox on that row. The tool adds the row twice; add more if needed. Choose array style: For repeated keys, select bracket notation ( a[]=1&a[]=2 ) or bracket-less ( a=1&a=2 ) from the dropdown. The output updates instantly. Copy the result: The encoded query string appears below, ready to paste after ? in your URL. No anchor ( # ) is included; add one if you need it.

Array conventions are not standardised. PHP, Rails, and most JavaScript frameworks use a[]=1&a[]=2 ; Python's requests library defaults to bracket-less a=1&a=2 ; some APIs expect commas or JSON. Always match what your API or framework documents. Empty values are different from missing keys. ?a= means "the key a is present with an empty string value"; omitting a entirely means "no such parameter". Some APIs treat these differently — check your endpoint's behaviour. Reserved characters are encoded. Characters like = , & , # , ? , and % inside your values will be percent-encoded so they don't interfere with the query-string syntax. Literal versions would break the string. Order can matter. Signed or authenticated URLs (AWS S3, Stripe webhooks, OAuth 1.0a) require parameters in a specific order before the signature is computed. This tool preserves your row order; reorder rows if needed before copying. Length limits and security. Browsers and servers typically cap query strings at 2–8 KB. Never put secrets, passwords, or tokens in the query string — they appear in server logs, browser history, and HTTP Referer headers. Use request headers or body instead.

Keys and values are percent-encoded (space becomes %20 , & becomes %26 , etc.) to ensure the URL is valid and unambiguous. The tool produces RFC 3986 compliant query strings suitable for URI/URL contexts. If you need form-encoded data (for POST bodies), spaces should be + instead — copy the output and replace %20 with + if required.

Query String Builder

Add key/value rows; get a correctly URL-encoded query string out. Supports array (a[]=1) and bracket-less repeated keys.

Base URL (optional)

Parameters

Array notation

Space encoding

Query string

Enter input above to see the result.

What is this for?

A query string is the part of a URL after the ? — a sequence of key/value pairs like ?name=John&age=30. Building one by hand is tedious and error-prone: spaces and special characters must be percent-encoded, the syntax is strict, and if you need to pass multiple values for one key, there are three or four competing conventions to choose from. This tool lets you type your keys and values in a simple form, mark any that should repeat, and generates a correctly-encoded query string ready to paste into your URL or API request.

When to use it

Crafting an API URL with several parameters that include spaces, accents, punctuation, or other special characters.
Building a tracking or campaign link (UTM tags, analytics parameters) without typos in the encoded values.
Constructing a deep link or share URL that has to survive being pasted into email, chat, or social media without corruption.
Testing which array notation an API endpoint expects — a[]=1, a=1&a=2, or something else — by trying each variant.
Debugging query-string issues by examining the exact encoded output and comparing it to what the server received.
Generating OAuth, webhook signature, or signed-request strings where parameter order and exact encoding matter.

How it works

Add rows: Type a key name and value for each parameter you want. The tool accepts any text in either field.
Mark repeats: If you want a key to appear multiple times (for arrays or multi-select fields), toggle the "multi" checkbox on that row. The tool adds the row twice; add more if needed.
Choose array style: For repeated keys, select bracket notation (a[]=1&a[]=2) or bracket-less (a=1&a=2) from the dropdown. The output updates instantly.
Copy the result: The encoded query string appears below, ready to paste after ? in your URL. No anchor (#) is included; add one if you need it.

Common gotchas

Array conventions are not standardised. PHP, Rails, and most JavaScript frameworks use a[]=1&a[]=2; Python's requests library defaults to bracket-less a=1&a=2; some APIs expect commas or JSON. Always match what your API or framework documents.
Empty values are different from missing keys. ?a= means "the key a is present with an empty string value"; omitting a entirely means "no such parameter". Some APIs treat these differently — check your endpoint's behaviour.
Reserved characters are encoded. Characters like =, &, #, ?, and % inside your values will be percent-encoded so they don't interfere with the query-string syntax. Literal versions would break the string.
Order can matter. Signed or authenticated URLs (AWS S3, Stripe webhooks, OAuth 1.0a) require parameters in a specific order before the signature is computed. This tool preserves your row order; reorder rows if needed before copying.
Length limits and security. Browsers and servers typically cap query strings at 2–8 KB. Never put secrets, passwords, or tokens in the query string — they appear in server logs, browser history, and HTTP Referer headers. Use request headers or body instead.

Encoding details

Keys and values are percent-encoded (space becomes %20, & becomes %26, etc.) to ensure the URL is valid and unambiguous.
The tool produces RFC 3986 compliant query strings suitable for URI/URL contexts. If you need form-encoded data (for POST bodies), spaces should be + instead — copy the output and replace %20 with + if required.