OPTIONS
Describes the communication options available for the target resource, such as allowed methods.
What it does
OPTIONS asks a server what it's allowed to do with a resource — which methods it supports, what headers it accepts, sometimes broader server capabilities. The response typically comes back in an Allow header rather than a meaningful body: Allow: GET, POST, PUT, DELETE tells the client exactly what verbs this endpoint accepts.
Most developers never issue OPTIONS by hand — it runs invisibly, in the background, every time a browser needs to CORS-preflight a cross-origin request.
Semantics
| Property | Value | Why it matters |
|---|---|---|
| Safe | Yes | Purely informational |
| Idempotent | Yes | Asking twice gives the same answer |
| Cacheable | No (by default) | Though Access-Control-Max-Age lets browsers cache preflight results specifically |
| Request body | No (typically) | The request line + Origin/Access-Control-Request-* headers carry everything needed |
| Response body | Optional | Often empty; Allow header does the real work |
Syntax & example request
OPTIONS /orders HTTP/1.1
Host: api.example.com
HTTP/1.1 204 No Content
Allow: GET, POST, OPTIONS
CORS preflight variant (what browsers actually send before a cross-origin POST with a JSON body):
OPTIONS /orders HTTP/1.1
Host: api.example.com
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: content-type
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Headers: content-type
Access-Control-Max-Age: 86400
curl example
curl -X OPTIONS https://api.example.com/orders -i
Common status codes returned
- 200 OK — options returned, possibly with a descriptive body → see 200
- 204 No Content — options returned via headers only, no body (most common) → see 204
OPTIONS vs HEAD vs 405
| OPTIONS | HEAD | 405 response | |
|---|---|---|---|
| Question answered | "What can I do here?" | "What's the metadata of this resource?" | Comes back when you already tried a method the server doesn't allow |
| Proactive or reactive | Proactive discovery | Proactive check | Reactive — result of a failed attempt |
If you're unsure whether an endpoint supports DELETE, OPTIONS lets you ask first. Skip that and just send the DELETE, and an unsupported method gets you a 405 Method Not Allowed instead — with the same Allow header telling you what would have worked.
Real-world usage
- CORS preflight — by far the most common real-world trigger. Browsers automatically send an OPTIONS request before certain cross-origin requests (non-simple methods, custom headers, non-form content types) to check the server permits it
- API discovery/documentation tooling probing what an endpoint supports
- Load balancer and server health checks (a lightweight, side-effect-free way to confirm a service is responding)
Security considerations
Access-Control-Allow-Origin: * on a preflight response combined with Access-Control-Allow-Credentials: true is invalid per spec and actively rejected by browsers — but misconfigured servers that reflect the request's Origin header back verbatim (instead of validating against an allowlist) accidentally create the same hole: any origin gets treated as trusted. Be explicit about which origins are allowed rather than reflecting whatever Origin header shows up.
FAQ
Why does my browser send an OPTIONS request I never wrote code for?
That's CORS preflight — the browser is checking with the server, before your actual request, whether a cross-origin call with this method/headers/content-type combination is allowed. It only happens for "non-simple" requests (custom headers, methods other than GET/HEAD/POST, or POST bodies that aren't form-encoded).
Can I skip the OPTIONS preflight?
Not from browser JavaScript for non-simple requests — it's enforced by the browser's CORS implementation, not something your frontend code controls. Server-side, you can reduce preflight frequency by setting a longer Access-Control-Max-Age so the browser caches the preflight result.
Does OPTIONS need authentication?
Preflight OPTIONS requests are sent without credentials by default (even for credentialed requests) and shouldn't require auth to respond — the server just needs to answer "here's what's allowed," not perform the actual authorized action.
Fun fact
OPTIONS existed in HTTP/1.1 (1997) over a decade before CORS (2009-2014) gave it its now-dominant real-world use case — for most of its early life, OPTIONS was a rarely-implemented, mostly-theoretical method for API discovery that few servers bothered to support properly.