What Is a Query String? The ?key=value Structure, Multiple Values, and Percent-Encoding

Have you ever seen a string like "?q=cat&page=2" tacked onto the end of a URL on a search results or product listing page? That is a query string (query parameters). It may look like an afterthought, but it is actually a fundamental mechanism of the Web for telling the server "which page to show, and under what conditions." This article explains, step by step, what a query string is, what structure it has, and how to design one well.

What Is a Query String

A query string is a string appended as part of a URL to pass extra information (parameters) to the server. It is written after the path portion of the URL, separated by a "?," and each key=value pair that makes up its contents is called a query parameter.

https://example.com/search?q=cat&page=2

In this example, "q=cat&page=2" after the ? is the query string. It tells the server two pieces of information: "the search term (q) is cat" and "the page is 2." The server reads these values and returns the corresponding page (the second page of cat search results).

A big feature of a query string is that you can access a page at the same path while changing only the conditions. By putting the search term, page number, sort order, filter conditions, and so on into the URL, you can reproduce a specific page state with just a link or bookmark. To see what the resulting string looks like, enter keys and values in the Query String Converter and check the assembled URL.

Structure: ?, &, and key=value

The structure of a query string is simple; once you learn the roles of three symbols, you can read it.

• ? (question mark): marks the boundary between the path portion of the URL and the query string. Everything after the first ? in the URL is the query string region.
• = (equals): within a single parameter, separates the key (name) from the value. In q=cat, the key is q and the value is cat.
• & (ampersand): joins multiple parameters. As in q=cat&page=2, each parameter is connected with &.

In other words, a query string is a structure that "begins with ? and joins any number of key=value pairs with &." Sometimes you will see parameters with an empty value (flag=) or just a key with no value, but it is enough to think of it as a repetition of key=value.

These symbols are reserved characters that express the structure. So when you want to include one of these symbols itself inside a key or value, you must replace it with another representation using percent-encoding, described below.

Expressing Multiple Values and Arrays

There are many situations where you want one key to hold multiple values, such as "filter by both red and blue." There is no single official format for arrays in a query string; instead, several conventional representations are used.

• Repeat the same key: write the same key multiple times, as in color=red&color=blue. Many frameworks interpret this form as an array.
• Add square brackets: append [] to the key, as in color[]=red&color[]=blue. This is common in PHP and similar.
• Combine with a delimiter: separate values within a single value using a comma or similar, as in color=red,blue. It is readable, but becomes ambiguous if the values themselves contain the delimiter.

Which forms can be accepted depends on the server-side implementation, so it is important that the sender and receiver agree on the interpretation. When in doubt, follow the specification of the framework or API you use. To confirm that a URL with multiple values is assembled correctly, list the parameters in the Query String Converter to avoid oversights.

Percent-Encoding

Query string values can include characters that cannot be written in a URL as-is, such as non-ASCII text, spaces, and symbols. That is where percent-encoding (URL encoding) comes in. It converts the target characters into a byte sequence and represents each byte as % followed by two hexadecimal digits.

For example, a space becomes %20, and a character outside ASCII is converted based on its UTF-8 byte sequence, such as %E7%8C%AB. When you want to use a structurally meaningful symbol like ?, =, or & as a value, you also encode it to distinguish it from its original meaning.

• Why it is needed: the characters usable in a URL are limited, and putting & or = directly into a value would break the structure.
• Note: a space can be represented as either %20 or + depending on context. Because the historical query-string convention sometimes uses +, be careful when decoding.

Doing encoding and decoding by hand is error-prone, so it is safest to leave the actual conversion to the URL Encoder. Paste a value, and you can check both the safely encoded result and the decoded result on the spot. When working with query strings, using the URL Encoder together with the Query String Converter makes the work smooth.

How It Is Used With GET

The query string is most often used in an HTTP GET request. GET is the method for "retrieving" information from the server, and it suits operations that produce the same result no matter how many times you repeat them (no side effects), such as searching, filtering, and paging. When you submit a form with GET, the input is automatically appended to the URL as a query string and passed to the server.

The advantage of using a query string with GET is that the state rides on the URL. You can bookmark a page with its search conditions, share it as a link, or recall it from the browser history. On the other hand, because the URL remains in history and server access logs, you should avoid putting secret values such as passwords or personal information into the query string. For sending such values, another method that carries the data in the body, such as POST, is more appropriate.

In short, it helps to understand the division of labor: a query string pairs well with GET uses like "retrieving results and sharing state," and is not suited to "sending secret information or changing server state."

Design Pitfalls: Order, Duplication, Length

Because a query string is so flexible, neglecting its design can lead to unexpected bugs and SEO problems. Here are the main points to watch.

1. Parameter order

From the server's view, ?a=1&b=2 and ?b=2&a=1 usually mean the same thing. But as URL strings they are different, so caches and analytics may count them as "different URLs." When the same content exists at multiple URLs, it can also cause search engines to treat it as duplicate content. It is best to keep the order consistent or to normalize it.

2. Duplicate keys

As noted above, many implementations treat a repeated key as an array, but some adopt only the first value or only the last value. An unintended duplicate key makes it hard to predict which value is used. If you duplicate, do so explicitly as an array; otherwise keep keys unique to be safe.

3. Length limit

The overall length of a URL has practical upper limits that vary by browser and server. Cramming in too many parameters risks the URL being cut off partway or causing an error. When you need to pass a large amount of data, you may need to use a POST body instead of a GET query string.

With only the minimal symbols ?, =, and & plus the mechanism of percent-encoding, the query string is a foundational technology for carrying rich information in a URL. Start by assembling and breaking down parameters in the Query String Converter to see the structure with your own eyes. When you need to encode a value, using the URL Encoder alongside it lets you build correct URLs while avoiding manual mistakes.

Please note that this article is intended to provide general information. The interpretation and limits of query strings differ depending on the browser, server, and framework you use. When implementing, be sure to check the latest official specifications and documentation before deciding.