Developer Tools

HTTP Methods Reference

Look up every HTTP method with safe, idempotent, cacheable, and body semantics, typical status codes, RFC references, and curl examples.

Search method or behaviour

Filter

Core HTTP methods

GET

Retrieve a representation of the target resource.

The default read method. Servers must not change resource state in response to a GET. Responses are cacheable by default when status, headers, and method allow it, which is why GET is the only method most CDNs cache out of the box. A request body on GET is allowed by the spec but has no defined meaning and is widely stripped by proxies, frameworks, and browsers, so do not rely on it.

Safe: Yes
Idempotent: Yes
Cacheable: Yes
Request body: No
Response body: Yes
Reference: RFC 9110 (HTTP Semantics)

Typical success codes

200 OK
204 No Content
206 Partial Content
304 Not Modified

Common error codes

301 Moved Permanently
401 Unauthorized
403 Forbidden
404 Not Found
410 Gone
429 Too Many Requests

When to use it

Fetching a single resource by id, like GET /users/42.
Fetching a collection with query filters, like GET /products?category=shoes&page=2.
Conditional reads with If-None-Match and ETags for 304 responses.
Range requests for partial downloads (Range: bytes=0-1023).

Pitfalls to avoid

Never put credentials, passwords, or tokens in the query string; they end up in proxy logs and browser history.
Do not perform side effects on GET. Crawlers, link prefetchers, and antivirus scanners will follow GET links and trigger them.
Sending a body is technically allowed by RFC 9110 but is rejected, stripped, or ignored by most clients and servers.
Long query strings can hit 414 URI Too Long; switch to POST with a body for large filter payloads.

Example request

GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
If-None-Match: "abc123"

Example response

HTTP/1.1 200 OK
Content-Type: application/json
ETag: "abc123"
Cache-Control: public, max-age=60

{"id":42,"name":"Ada Lovelace"}

Example curl command

curl -i https://api.example.com/users/42

Browse 16 methods

Click a card for details

Core HTTP methods

Defined by RFC 9110 (HTTP Semantics) and RFC 5789 (PATCH). The methods every API and browser understands.

WebDAV methods

Defined by RFC 4918 for WebDAV file-system style remote stores. Used by Finder, calendar clients, and DAV-aware editors.

Specialized methods

Niche methods you usually do not implement yourself but should recognize on the wire.

Compare two methods

Pick any two methods to see how they differ on safety, idempotency, cacheability, and body handling. Useful for clarifying PUT vs PATCH, POST vs PUT, or GET vs HEAD.

Method AMethod B

Property	PUT	PATCH
Safe	No	No
Idempotent	Yes	Sometimes
Cacheable	No	No
Request body	Yes	Yes
Response body	Sometimes	Sometimes

Rows where the two methods differ are highlighted in white. This is static reference data; no requests are sent.

Reference. Method properties at a glance

Safe	Idempotent	Cacheable	Req body	Res body	RFC
Yes	Yes	Yes	No	Yes	RFC 9110 (HTTP Semantics)
Yes	Yes	Yes	No	No	RFC 9110
No	No	Rare	Yes	Sometimes	RFC 9110
No	Yes	No	Yes	Sometimes	RFC 9110
No	Sometimes	No	Yes	Sometimes	RFC 5789
No	Yes	No	Rare	Sometimes	RFC 9110
Yes	Yes	Rare	Rare	Sometimes	RFC 9110
No	No	No	No	No	RFC 9110
Yes	Yes	No	No	Yes	RFC 9110
Yes	Yes	No	Sometimes	Yes	RFC 4918 (WebDAV)
No	Yes	No	Yes	Yes	RFC 4918 (WebDAV)
No	Yes	No	Rare	Sometimes	RFC 4918 (WebDAV)
No	Yes	No	Rare	Sometimes	RFC 4918 (WebDAV)
No	Yes	No	No	Sometimes	RFC 4918 (WebDAV)
No	No	No	Yes	Yes	RFC 4918 (WebDAV)
No	Yes	No	No	No	RFC 4918 (WebDAV)

Sometimes means the spec allows it but real implementations vary. Rare means it is technically allowed but almost never used.

How to use

Search by method (GET, PATCH, DELETE) or by behaviour (idempotent, cacheable, cors). The list filters live as you type.
Use the property filter chips to narrow the list to safe, idempotent, cacheable, or body-bearing methods.
Click any method card to pin it as the active selection. The detail panel shows safety, idempotency, cacheability, body semantics, success codes, error codes, use cases, pitfalls, and example HTTP and curl snippets.
Open the Compare two methods panel and pick any two from the dropdowns to print a row-by-row diff. Rows where the methods differ are highlighted in white.
Use Copy curl to grab the curl command, Copy method to grab just the verb, or Copy on any example panel to copy the HTTP wire format.

About this tool

HTTP Methods Reference is a fast, browser-only lookup for every HTTP request method defined by the core HTTP specifications. Each entry covers the canonical semantics from RFC 9110 (HTTP Semantics), RFC 5789 (PATCH), and RFC 4918 (WebDAV): whether the method is safe (does not change server state), idempotent (repeating produces the same outcome), cacheable (responses can be cached by intermediaries), whether the request typically carries a body, and whether the response typically carries a body. Every method shows its one-line meaning, a detailed paragraph that explains how real APIs use it, the typical success status codes (200, 201, 202, 204, 207, and so on), the common error codes you should be ready to handle (400, 401, 403, 404, 409, 412, 415, 422, 429), a list of concrete use cases, a list of pitfalls and footguns to avoid, an example HTTP wire-format request, an example response, and a copyable curl command that reproduces the request from the terminal. Methods are grouped into core HTTP (GET, HEAD, POST, PUT, PATCH, DELETE, OPTIONS), WebDAV (PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK), and specialized methods (CONNECT for proxy tunneling, TRACE for path debugging). The search box accepts a method name (GET, PATCH, CONNECT) or a behaviour keyword (idempotent, cors, webdav, upload, retry), and typing an exact method name auto-pins it as the active selection. Property filter chips narrow the list to only safe methods, only idempotent methods, only cacheable methods, or only methods with a request or response body, which is the fastest way to answer questions like which HTTP methods are idempotent or which methods are safe to retry. A side-by-side compare panel lets you pick any two methods (PUT vs PATCH, POST vs PUT, GET vs HEAD) and prints a property-by-property diff, with rows that disagree highlighted in white so the answer is unambiguous. A reference table at the bottom of the page summarises every method on a single line for quick scanning. This is a reference tool, not a request runner: it never sends HTTP traffic, never connects to a remote server, and works offline once the page has loaded, so your queries are private and never logged. Useful for API designers picking the right verb for a new endpoint, frontend engineers explaining why a PATCH retry duplicated a record, backend engineers wiring up CORS preflight responses, technical writers drafting REST documentation, students learning REST for the first time, and anyone debating PUT versus PATCH on a pull request review.

Free to use. Works in your browser. No signup, no login.

Related tools

HTTP Methods Reference

Retrieve a representation of the target resource.

How to use

About this tool

You may also like

HTTP Status Codes

HTTP Headers Parser

CORS Headers Generator

MIME Type Lookup

Port Number Lookup

cURL Command Builder

URL Parser