How to Use URL Query Parameters

Adding query parameters to a request

You can add query parameter to your request either in the URL or in the Query Parameters field.

https://www.example.com?query1=value1&query2=value2
https://www.example.com?query1=value1&query2=value2#hash1
https://api.example.com/v2/resources/1?query1=value1&query2=value2

Both methods are valid, if you add query params in the URL and also in the Query Parameter fields they'll be concatenated and all query parameters will be used.

Why query parameters matter in a load test

Query parameters are part of the request URL, so the server (and anything in front of it, like a CDN, reverse proxy, or WAF) sees them as part of what it is being asked for. This matters in two ways during a load test:

• Routing and filtering: many APIs use query parameters to select a resource, page, or filter (?page=2, ?status=active, ?locale=en). If your test only ever hits one combination of parameters, you are only testing one code path. A search endpoint that is fast for ?q=shoes might behave very differently for ?q= (empty) or a query with many filters applied at once.
• Caching: a CDN or reverse proxy commonly treats the full URL, including its query string, as the cache key. Adding a query parameter that changes on every request (a cache-busting timestamp, a random id) can accidentally turn a cacheable endpoint into one that misses cache on every single virtual user. That will look like a much slower, much more loaded backend than production traffic would ever produce, when the real cause is the query string itself.

Static parameters vs. per-request values

The parameters you type into a test request are static: every virtual user sends the exact same query string on every iteration. That is fine for most conceptual testing (verifying an endpoint behaves correctly and stays fast under load), but keep two things in mind:

• You cannot make a query parameter "global" and have it apply automatically to every request in the test, for example an API key passed as ?api_key=.... It needs to be added to every request URL (or Query Parameters field) individually, wherever it's required.
• If the endpoint you're testing expects a different value per call, a pagination cursor, a unique order id, a one-time token, a fixed query string will only exercise that single value, repeated. Real traffic hits many different values, so results based on one static value tell you about that one case, not the full range of production behavior.

Common pitfalls

• Forgetting to URL-encode: spaces, &, =, and other reserved characters inside a value need to be percent-encoded, otherwise the string gets parsed as extra parameters instead of a single value.
• Confusing the fragment with a parameter: anything after # (like #hash1 in the example above) is a URL fragment, not a query parameter. Browsers keep fragments client-side and never send them to the server, so they have no effect on server-side load testing.
• Duplicating a parameter in both places: since URL and Query Parameters field values are concatenated, adding the same key in both places sends it twice, which can trigger different, and unintended, behavior on servers that only expect one value per key.

For related guidance, see https://loadfocus.com/docs/knowledge-base/using-valid-url-endpoints and https://loadfocus.com/docs/guides/load-testing/how-to-url-query-parameters.