HTTP Methods Reference
Every standard HTTP request method, searchable. Filter by category and see what each method does.
| Method or concept | Category | What it does |
|---|---|---|
GET | Method | Requests a representation of the target resource; used to retrieve data and should not change server state. Safe, idempotent, and cacheable. |
POST | Method | Submits data so the server can create a resource or trigger processing. Neither safe nor idempotent. |
PUT | Method | Creates or fully replaces the target resource with the request body. Idempotent, so repeating it lands on the same state. |
PATCH | Method | Applies a partial modification to the target resource. Not guaranteed to be safe or idempotent. |
DELETE | Method | Removes the target resource. Idempotent, since deleting an already-gone resource leaves the same end state. |
HEAD | Method | Identical to GET but returns only the status line and headers, with no response body. Safe and idempotent. |
OPTIONS | Method | Asks which methods and capabilities the target supports; also used by browsers as the CORS preflight request. |
TRACE | Method | Performs a message loopback so the client can see what the final server received. Safe, but often disabled for security. |
CONNECT | Method | Establishes a TCP tunnel to the target, commonly used to reach an HTTPS origin through a forward proxy. |
Safe methods | Property | GET, HEAD, OPTIONS, and TRACE are read-only by contract: they are not expected to change server state. |
Idempotent methods | Property | GET, HEAD, OPTIONS, TRACE, PUT, and DELETE reach the same end state whether the request is sent once or many times. |
Cacheable methods | Property | By default only GET and HEAD responses are cacheable; a POST response can be cached only when it explicitly allows it. |
Methods that usually carry a request body | Property | POST, PUT, and PATCH normally send a request body holding the data to create or update. |
Methods usually sent without a body | Property | GET and DELETE are normally sent with no request body; a body on GET has no defined semantics in HTTP. |
Is POST safe or idempotent? | Property | No. POST is neither safe nor idempotent, so repeating it may create duplicate resources or repeat an action. |
Idempotent but not safe | Property | PUT and DELETE change server state yet are idempotent, so an identical retry still reaches the same final state. |
Create maps to POST | REST usage | In CRUD over REST, creating a new resource inside a collection maps to POST. |
Read maps to GET | REST usage | Reading or listing resources maps to GET, which is safe and cacheable. |
Update maps to PUT or PATCH | REST usage | Updating maps to PUT for a full replacement or PATCH for a partial change. |
Delete maps to DELETE | REST usage | Removing a resource maps to DELETE. |
PUT vs PATCH | REST usage | PUT replaces the entire resource and is idempotent; PATCH applies a partial change and is not guaranteed idempotent. |
POST vs PUT | REST usage | POST creates a resource under a server-chosen URL and is not idempotent; PUT writes to a client-chosen URL and is idempotent. |
POST to a collection, PUT to an item | REST usage | POST /articles adds a new item to the collection; PUT /articles/42 creates or replaces the item at that exact URL. |
405 Method Not Allowed | REST usage | Returned when the method is known but not supported for that resource; the 405 response must include an Allow header. |
Allow header lists methods | REST usage | The Allow response header lists the methods a resource supports, for example GET, POST, HEAD. |
201 Created after a successful POST | REST usage | A POST that creates a resource usually returns 201 Created with a Location header pointing at the new resource. |
204 No Content after DELETE or PUT | REST usage | A successful DELETE or PUT with nothing to send back commonly responds with 204 No Content. |
No methods or concepts match your search.
Runs entirely in your browser. Nothing you type is sent anywhere; open DevTools and watch the Network tab to verify zero requests.
What this tool does
This is a searchable reference for the HTTP request methods defined by RFC 9110, plus the properties and REST usage patterns that go with them. Every row lists a method or concept, a category badge (Method, Property, or REST usage), and a one-sentence plain-English explanation. Type in the filter box to narrow the table by keyword, or tap a category button to show just one group. The whole dataset is baked into the page, so it works offline and sends nothing anywhere.
How to use it
Start typing in the Filter box. Entering PUT narrows the
list to the PUT method and the rows that compare it; entering idempotent
surfaces every row about idempotency; entering CORS jumps to OPTIONS. The
category buttons (All, Methods, Properties, REST usage) combine with the
text filter, so you can pick Properties and type cache to zero
in on which methods are cacheable. Clear the box to see everything again. Nothing is
submitted and there is no result limit.
Common use cases
- Looking up what a method does when reading API documentation or server logs.
- Choosing the right method for an endpoint, such as PUT versus PATCH or POST versus PUT.
- Checking which methods are safe, idempotent, or cacheable before adding retries or caching.
- Mapping CRUD operations onto HTTP methods when designing a REST API.
- Explaining method semantics to a teammate with a precise, shared definition.
Common pitfalls
- PUT is not PATCH. PUT replaces the whole resource, so sending a partial body with PUT can blank out the fields you omitted. Reach for PATCH when you only mean to change part of a resource.
- POST is not idempotent. Retrying a POST after a timeout can create a duplicate. Use an idempotency key, or switch to PUT against a known URL, when you need retries to be safe.
- Safe does not mean enforced. Safe methods are a contract, not a guarantee. A GET handler that quietly changes state still breaks caches, prefetching, and crawlers that trust GET to be side-effect free.
- The OPTIONS preflight is automatic. Browsers send an OPTIONS preflight for many cross-origin requests, and the server must answer it with the correct Allow and Access-Control headers or the real request never runs.
Frequently asked questions
- What does idempotent mean for an HTTP method?
- A method is idempotent when sending the same request once or many times leaves the server in the same final state. GET, HEAD, OPTIONS, TRACE, PUT, and DELETE are idempotent, so a client can safely retry them after a network error. POST is not idempotent, because two identical POSTs may create two resources.
- What is the difference between PUT and PATCH?
- PUT replaces the entire target resource with the body you send, so any field you leave out can be wiped; PUT is idempotent. PATCH applies only a partial change described by the request body and is not guaranteed to be idempotent. Use PUT for a full replacement and PATCH when you want to update just a few fields.
- What is the difference between POST and PUT?
- POST usually creates a new resource under a URL the server picks, and it is neither safe nor idempotent, so retrying can create duplicates. PUT writes to a specific URL the client already knows and is idempotent, so repeating it is harmless. A rule of thumb: POST to a collection to add an item, PUT to an item URL to create or replace that exact item.
- Which HTTP methods are safe?
- GET, HEAD, OPTIONS, and TRACE are defined as safe, meaning they are read-only and are not expected to change server state. Safe is a contract, not an enforcement: a server can still be written to mutate state on a GET, but doing so breaks caches, prefetching, and crawlers that assume GET is side-effect free.
- What is OPTIONS used for in CORS?
- Before certain cross-origin requests, a browser sends an automatic OPTIONS request called a preflight to ask whether the real request is allowed. The server answers with Access-Control-Allow-Origin, Access-Control-Allow-Methods, and related headers. If the preflight fails or is not answered correctly, the browser blocks the actual request.
- Does this tool send anything I search to a server?
- No. The full list of methods and concepts is embedded in the page, and every filter runs in your browser with JavaScript. You can confirm it by opening DevTools and watching the Network tab: typing in the search box makes zero requests.
Cite this tool
For academic, journalistic, or technical references. Pick a format:
Citations use 2026 as the publication year. Access date is left as a fillable placeholder where the citation style expects one.