What is the HTTP QUERY method?

When a program needs to talk to a website or online service (e.g. to look something up, share a piece of data, or make a change to the site) it uses an HTTP method. You can think of these methods as verbs that tell the server what kind of request is coming. The two most common are GET (used to read or fetch something) and POST (used to send data in). In 2026, a new method joined the list: QUERY, defined in an official web standard called RFC 10008.

The HTTP QUERY method is a verb built for one job: asking a service a question and getting an answer back. What makes it special is where it puts the details of that question. Instead of squeezing them into the web address like GET, QUERY follows POST and tucks them into a separate part of the request called the body. It’s also designed to be a pure lookup—it only reads information, never changes that information, and can be safely sent again if something goes wrong. That makes it a strong fit for searches and other read-only requests that are too big or too complicated to fit in a normal web link.

In this article, we’ll look at why QUERY was created, how it works in plain terms, where it’s useful (especially for search), and how ready it is to use today.

A quick refresher on HTTP methods

Every time you load a page or use an app, your device quietly sends HTTP requests, each one labeled with a method. GET asks for information, like opening a web page. POST sends information in, like submitting a form. There are a few others, such as PUT and DELETE for updating or removing things, but most of the web runs on GET and POST. Each method also comes with a set of expectations about what it does, and browsers, servers, and other software rely on those expectations to handle requests correctly. QUERY adds a new option designed to fill a specific gap between GET and POST.

Why was a new HTTP method needed?

For years, developers who needed to send a lookup had only two good options, and both came with drawbacks.

The first is GET. The GET method is perfect for simple requests, but it carries all of its details inside the web address itself. That becomes a problem when a request gets long or complicated: web addresses have length limits, they often get saved in server logs and browser history (not ideal if the request contains private information), and they simply can’t hold a large or detailed question.

The second option is POST. The POST method can carry plenty of detail in its body, so it doesn’t have the size problem. But POST is the method normally used to create or change things, so other software can’t assume a POST is just a harmless lookup. That means a POST can’t always be safely repeated after a dropped connection, and its answers usually can’t be saved and reused the way a response to GET can.

QUERY was created to close that gap. It carries its details in the body, like POST, but it clearly signals that the request is a read-only lookup, like GET. That way, all the software in between (such as browsers, servers, and the systems that help speed up the Web) knows the request is safe to repeat and its answer is safe to reuse.

How does the QUERY method work?

At a high level, a QUERY request follows a few simple steps:

1. Sending the question in the body
   The program sends a QUERY request and places the details of what it’s asking (such as search words, a database-style query, or a list of filters) in the body of the request. It also adds a label that says what format those details are in, so the server knows how to read them.

2. Reading without changing anything
   The server treats the request as read-only. It looks something up and returns a result, but it never modifies the targeted resource. Because the targeted resource is not changed in any way, the request can be sent again if the connection drops, with no risk of causing damage.

3. Getting the answer back
   The server replies with the results, just as it would for a GET request. A normal “success” response means the lookup worked and the answer is included.

4. Saving and reusing the answer
   Because a QUERY answer can be saved (a process called caching) the same request can be served faster the next time it’s made. The server can also hand back a plain web link that repeats the same lookup later with a simple GET, so the program doesn’t have to send all the details over again.

A note on some common technical jargon with QUERY

If you read about QUERY elsewhere, you’ll probably run into two technical words:

• Safe: While the word “safe” sounds like it means private or secure, in the case of the QUERY method “safe” simply means the request reads data without changing that data.
• Idempotent: The word “idempotent” is just a long way of saying you can send the same request more than once without causing any extra effect.

Both words point to the same simple idea: QUERY only looks things up, so repeating it is harmless. (If you want the exact definitions, they come from the main HTTP standard, RFC 9110.)

Where is the QUERY method used?

QUERY is still new, but it’s a natural fit for a handful of situations:

• Search tools and APIs: Search is the clearest example. QUERY lets a search API offer a single address that is read-only, reusable, and safe to retry, even when the search is too big or detailed to fit in a web link.

• Large or private requests: Long filters, database-style queries, and the vector embeddings used in AI search can all ride in the body, instead of showing up in a website address that might get logged.

• Faster repeat lookups: Because answers can be saved and reused, common searches can come back faster and with less repeated work, which cuts down on wait time.

• Simpler API design: Instead of building many separate Web addresses to cover every kind of request (one for active users, one for premium users, and so on) a service can offer a single QUERY address that accepts all those details in the body. This translates to fewer endpoints to build, document, and maintain.

It’s worth adding that QUERY isn’t meant to replace GET. For short questions (and any time you want a link you can share or bookmark, and that will show the filters right in the site address) GET is still the better choice. QUERY is for questions that are too long, too complex, or too sensitive to put in a web address.

How widely supported is QUERY right now?

Because QUERY only became an official standard in 2026, support is still limited. Many servers, browsers, and other Web tools don’t fully handle QUERY yet, so a request that works in one place might not work in another. In browser environments specifically, QUERY is not CORS-safelisted, which means cross-origin requests require a preflight OPTIONS exchange before the QUERY request itself is sent.

Adoption across the wider Web is still in its early days, so for now QUERY is best treated as something to plan for rather than something to depend on in production.

The future of QUERY, and why it matters for search

QUERY may look like a small addition, but it fills a real gap. For the first time, a lookup that’s too big for a web address can still behave like a proper read: it can be clearly read-only, safe to repeat, and easy to save and reuse. That’s exactly the kind of request that search tools make all the time.

As more servers, browsers, and services add support, QUERY could make search requests cleaner, faster, and more private, especially for the complex queries that power AI search and retrieval.

Related terms

Web search API, programmable search engine, structured output, latency, rate limiting, semantic search, REST API, idempotency, HTTP.