Glossary

Query string

A query string adds optional parameters to a URL, such as filtering, pagination and sorting. It forms part of the address and may therefore appear in history, logs, analytics and referrers.

Short definition

Optional URL context, not a secret channel or SQL query.

A query string begins with a question mark, and individual parameters are commonly separated with &. The address https://api.example.cz/orders?status=paid&page=2 has /orders as its path, while status=paid and page=2 form the query string. Each parameter has a name and optional value; the specific website or API contract defines its precise meaning.

Parameters must be URL-encoded and converted from text to expected types on the server. The fact that a client sent page=2 or sort=-createdAt does not mean the server should trust it. The application checks permitted names, values, ranges, tenant and permissions just like any other input.

The problem it solves

A shareable read view without creating a new path for every variant.

Query parameters work well for limited, documented context that a user can save or send to someone else.

filtering an order list by status, date range or customer
pagination and page size in an administration interface or public catalogue
sorting by a predefined set of columns and directions
a search term that does not contain sensitive data
an optional representation of an API read response when explicitly supported by the contract

Practical example

Filtering orders with restricted sorting.

The administration interface displays only paid orders, the second results page and newest-first sorting. The server does not treat the sort parameter as a SQL expression; it maps it to one of a predefined set of permitted variants. It also validates the page number and obtains the current tenant from the verified identity, not the URL.

The example contains no token or customer email address. If the user bookmarks the URL or it appears in a reverse proxy log, it contains only a harmless filter.

URL

https://api.example.cz/orders?status=paid&page=2&sort=-createdAt

status = paid
page   = 2
sort   = -createdAt

How it works

From a URL parameter to a safe application filter.

The client writes text into the URL; the server then turns it into verified application input.

The client builds a URL Values are encoded with a standard URL encoder. Manual string concatenation commonly handles spaces, ampersands and non-ASCII characters incorrectly.
The browser or API client sends a request The query is part of the request target. The fragment after # is not sent in a normal HTTP request and is therefore not a query string.
The framework parses parameters The application receives text values and must decide whether missing, empty or repeated values make sense in its contract.
Validation creates a permitted filter page becomes a positive integer, status is checked against the list of states and sort is selected from an allowlist rather than an arbitrary SQL fragment.
The response preserves a clear contract The server returns results or a safe validation error. Caching and canonical URLs must account for which parameters genuinely change the content.

Important concepts

Parameter names, values, encoding and repetition.

The URL standard governs URL syntax, but parameter semantics always belong to the application or API.

Path and query

The path typically identifies a resource such as /orders. The query changes the read view, such as ?status=paid. The boundary is not absolute but should remain stable and documented.

URL encoding

Characters with special meaning and data outside the safe character set require percent-encoding. Encoding is neither sanitisation nor semantic validation of a value.

Repeated parameters

Addresses such as ?tag=php&tag=api are possible, but frameworks can interpret repetitions differently. The contract should say whether they form a list, cause an error or use the last value.

Empty and missing values

q=, q, and an entirely absent q need not mean the same thing. The application must distinguish a default filter, a request for an empty value, and invalid input.

Queries and caching

Parameters that change the response belong in the cache key. Tracking parameters, by contrast, often should not create duplicate canonical pages or fragment the cache.

Benefits and limitations

Readable addresses at the cost of limited privacy and length.

Benefits

a specific filter or list page can be shared and saved
it works naturally with navigation, caching and browser history
a read API has a clear, documentable approach to filtering and pagination
parameters are easy to combine while their rules remain simple

Limitations and mistakes

sensitive data can leak into history, access logs, analytics or the Referer header
very long URLs encounter practical limits in clients, proxies and servers
unrestricted parameters create an unclear contract, cache fragmentation and complex queries
directly inserting parameters into SQL or commands introduces injection risk
the query must not be the only source of authorized tenant context

Practical use

Use it to describe a view, not confidential state or a large form.

An order list can reasonably use status, page and sort. An endpoint that creates an order instead accepts data in the POST body because it is a state-changing operation with a larger structure and more sensitive context. Although the HTTP method alone cannot guarantee correct application behaviour, the URL design should support these semantics.

For search, it makes sense to define a maximum length, normalize empty values and distinguish a public filter from a personalised view. A token, password, email address in a campaign link, or session identifier does not belong in a query: an address is more visible and easier to copy than a secure HTTP header or server-side session.

What to consider

Describe parameters explicitly, build them safely and validate them strictly.

Every parameter is input from an untrusted client and part of a public interface.

use clear parameter names and document their type, default value and limit
generate URL values with a standard encoder and never concatenate them as unverified strings
validate numbers, dates, enum values, repetitions and maximum length before application use
select dynamic sort columns and directions from an allowlist and never take non-parameterizable identifiers directly from the client
do not put tokens, passwords, session IDs or unnecessary personal data in an address
consider canonicalisation and caching rules when multiple address variants return the same content

Common questions

Query parameters in practice

Is a query string part of a URL?

Yes. It usually begins with a question mark and contains parameters. It is not the entire URL, which also includes the scheme, host, path and optional fragment.

Is the fragment after # sent to the server?

Normally not. The client handles the fragment, for example to scroll to part of a page. The query string, by contrast, is sent in the HTTP request.

Can I put an access token in the query?

Not a sensitive or long-lived token. A URL can appear in history, logs and referrers. A secure header or server-side session is more appropriate for permissions.

Does the order of query parameters matter?

It should not without a clearly documented reason. The application should define repetition and canonicalisation behaviour because comparing URLs as plain strings is often misleading.

How I design APIs in practice

I connect addresses, filters and permissions into one clear contract.

For integration and e-commerce backends, I address stable URLs, input validation, safe pagination and predictable error responses.

How I work with APIs and integrations Discuss your project without obligation