HTTP Methods: Safe, Idempotent, Cacheable

What is an HTTP method?

An HTTP method — the verb at the start of a request, GET or POST or DELETE — says what the client wants done with the resource it names. There are far more of them than most people meet: IANA's registry holds 41 names, only nine of which come from the core HTTP specification. The rest arrive from WebDAV, from versioning extensions, from CalDAV, from HTTP/2, and from three standalone specs.

RFC 9110 gives every method three properties. It is safe if its semantics are essentially read-only, so a crawler can issue it without fear. It is idempotent if sending the same request twice has the effect of sending it once, so a proxy can retry it after a dropped connection. And it is cacheable if a cache may store the response and reuse it later.

Those three answers are what a page about HTTP methods should give you, and they do not all live in the same place — which is the reason this page exists rather than a copy of the registry.

How to use it

1. Type a method name. Case does not matter. You get the three properties, what each one means in practice for a client and a cache, and a link to the section of the RFC that says so.
2. Or search the whole registry. The table below holds all 41 names. Searching an RFC number — 9110, 4918 — brings back everything that document defines.
3. Narrow it to the ones you will actually meet. One checkbox drops the table to the nine names RFC 9110 registers itself, which is every method most APIs ever send.

The property the registry does not record

RFC 9110 section 16.1.1 lists the fields a method registration must carry: the name, whether it is safe, whether it is idempotent, and a pointer to the specification. Four fields, and cacheability is not among them. Yet section 16.1.2 of the same document says a new method definition needs to indicate whether it is safe, idempotent and cacheable. Three properties named one section apart, two of them written down.

So the third has to be read out of the defining documents, and there are thirteen of those. Doing that gives a clean answer for most rows and an awkward one for the rest: 3 methods are plainly cacheable, 3 more only under stated conditions, 26 are explicitly not, and 9 specifications never mention caching at all.

That silence is not an unknown, though, and this is the sentence that makes the table complete rather than partial. Section 9.2.3: for a cache to store and use a response, the method needs to explicitly allow caching and detail the conditions, and a method definition that does not do so cannot be cached. Silence is a refusal, by default, written into the standard. The table still shows those nine as not stated rather than as no, because what a specification refuses and what it never considered are different facts and only one of them can be quoted at you in a code review.

The wording differs too, in ways that are worth seeing. Eight methods say responses MUST NOT be cached, which binds the cache. Ten — the versioning family, plus MKCALENDAR — instead require the server to send Cache-Control: no-cache, which binds the server. SEARCH says only SHOULD NOT. PROPFIND says results may be cached, with care. The table records which form of words produced each answer.

The rows people get wrong

PATCH is not idempotent. It sits beside PUT in every REST tutorial and behaves differently: applying the same patch twice may not be the same as applying it once, so the registry records it as neither safe nor idempotent, and RFC 9110 says a proxy must not automatically retry a request like that. DELETE, meanwhile, is idempotent despite sounding like the most destructive verb on the list — deleting something twice leaves it deleted.

Safe does not mean cacheable. Nine methods are safe and only three of them — GET, HEAD and QUERY — are plainly cacheable. OPTIONS and TRACE are read-only and their responses are explicitly never cacheable. REPORT is safe, idempotent, and its specification says nothing about caching at all.

The reverse fails as well: POST and PATCH are neither safe nor idempotent, and both are cacheable under conditions. A POST response can be stored when it carries explicit freshness information and a Content-Location matching the request target — and then it may only be used to answer a later GET or HEAD, never another POST. RFC 9110 notes in passing that the overwhelming majority of caches implement only GET and HEAD anyway, which is a specification conceding that reality has diverged from it.

Two more curiosities. QUERY became a standards-track method in June 2026: safe, idempotent, cacheable, and carrying a request body — the thing people have wanted every time they tried to put a long search into a GET. Its cache key must incorporate the body, which is exactly why it took so long. And the registry contains an entry named simply an asterisk, which is not a method: it is reserved so that nobody can ever register one, because that name would collide with the wildcard in fields like Access-Control-Request-Method.

What this page cannot tell you

These are properties of the method, not promises about a server. A server can implement GET so that it deletes something; the specification is clear that this makes the server wrong rather than making GET unsafe. What the properties buy you is the right to assume: a crawler prefetching safe methods, a proxy retrying idempotent ones, a cache storing cacheable ones, all without asking anyone's permission.

The table is also a snapshot of a registry that grows. QUERY was added in 2026 and nothing here predicts what will be added next. Where a row says a specification is silent, that is a statement about the document as it stands, not a prediction that it will stay silent.

And a method being registered says nothing about whether anything supports it. Most of these 41 names belong to WebDAV and its extensions, which a normal web server will answer with 405.

Why is it free?

The whole registry is a few kilobytes shipped with the page and searched in your browser. Nothing you type is uploaded, nothing is logged, and there is no account to make.

No sign-up, no limits, and no watermark on anything you copy out.