What Is a Preflight Request?
Understand how CORS preflight requests work, why browsers perform them before certain cross-origin requests and how to configure servers correctly.
A preflight request is an automatic HTTP OPTIONS request that a browser sends before certain cross-origin HTTP requests. Its purpose is to ask the server whether the actual request is permitted under the Cross-Origin Resource Sharing (CORS) policy before any potentially unsafe action is performed.
Developers frequently encounter preflight requests when building APIs or frontend applications that communicate with servers hosted on different origins. Understanding why browsers perform preflight checks makes CORS-related errors much easier to diagnose and resolve.
What Is a Preflight Request?
A preflight request is a permission check performed by the browser. Instead of immediately sending the intended cross-origin request, the browser first sends an HTTP OPTIONS request to determine whether the server accepts the planned method, headers and origin.
Why Browsers Use Preflight Requests
Without a preflight check, browsers could send potentially unsafe cross-origin requests directly to servers. Preflight requests give the server an opportunity to explicitly approve or reject requests before they are executed.
How a Preflight Request Works
| Step | Description |
|---|---|
| 1 | Browser prepares a cross-origin request |
| 2 | Browser sends an HTTP OPTIONS request |
| 3 | Server responds with CORS headers |
| 4 | Browser decides whether the actual request is allowed |
| 5 | If approved, the browser sends the original request |
HTTP OPTIONS Method
Preflight requests always use the HTTP OPTIONS method. Unlike methods such as GET or POST, OPTIONS is designed to ask a server which communication options are supported without requesting the actual resource.
OPTIONS /api/users HTTP/1.1When Is a Preflight Request Sent?
Not every cross-origin request requires a preflight check. Browsers perform preflight requests only when certain conditions indicate that the request is more complex than a standard simple request.
- Using HTTP methods such as PUT, PATCH or DELETE.
- Sending custom request headers.
- Using non-simple Content-Type values.
- Making requests that do not meet the requirements for simple requests.
Simple Requests vs Preflight Requests
| Request Type | Preflight Required |
|---|---|
| Simple GET | No |
| Simple POST | Usually No |
| PUT | Yes |
| PATCH | Yes |
| DELETE | Yes |
| Request with custom headers | Yes |
Headers Sent During Preflight
The browser includes several headers that tell the server what the upcoming request will look like. The server uses this information to determine whether the request should be permitted.
| Header | Purpose |
|---|---|
| Origin | Identifies the requesting origin |
| Access-Control-Request-Method | Specifies the planned HTTP method |
| Access-Control-Request-Headers | Lists custom request headers |
Server Response to a Preflight Request
If the server allows the upcoming cross-origin request, it responds to the OPTIONS request with the appropriate CORS headers. The browser evaluates these headers before deciding whether the actual request may proceed.
| Response Header | Purpose |
|---|---|
| Access-Control-Allow-Origin | Specifies allowed origins |
| Access-Control-Allow-Methods | Lists permitted HTTP methods |
| Access-Control-Allow-Headers | Lists permitted request headers |
| Access-Control-Max-Age | Specifies how long the preflight response may be cached |
Access-Control-Max-Age
Browsers can cache successful preflight responses for a period of time. The Access-Control-Max-Age header tells the browser how long it may reuse the result without sending another OPTIONS request for similar requests.
What Happens After a Successful Preflight?
Once the browser confirms that the server allows the requested origin, method and headers, it automatically sends the original HTTP request. The preflight request itself does not retrieve or modify application data—it only verifies permission.
What Happens If Preflight Fails?
If the server rejects the preflight request or omits required CORS headers, the browser blocks the actual request from being exposed to JavaScript. The failure usually appears as a CORS error in the browser's developer tools.
| Server Response | Browser Behavior |
|---|---|
| Valid CORS headers | Actual request is sent |
| Missing required headers | Request blocked |
| Origin not allowed | Request blocked |
| Method not allowed | Request blocked |
Common Situations That Trigger Preflight
Although many developers associate preflight only with PUT or DELETE requests, browsers trigger preflight whenever a request falls outside the definition of a simple request.
- Sending an Authorization header.
- Using custom X-* request headers.
- Uploading JSON with certain request configurations.
- Making PUT, PATCH or DELETE requests.
- Using non-standard request headers.
Performance Considerations
Because every preflight request adds an additional network round trip before the actual request, excessive preflight traffic can increase latency. Appropriate caching through Access-Control-Max-Age and careful API design can reduce unnecessary preflight requests.
Debugging Preflight Requests
Browser Developer Tools provide the easiest way to inspect preflight requests. The Network panel shows both the OPTIONS request and the subsequent request, allowing developers to verify request headers, response headers and HTTP status codes.
Common Mistakes
- Blocking the OPTIONS method on the server.
- Returning incomplete CORS headers.
- Forgetting to allow required request headers.
- Using wildcard origins with credentials.
- Assuming every cross-origin request triggers a preflight request.
- Debugging only the frontend without checking server responses.
Preflight Requests and REST APIs
Modern REST APIs frequently receive preflight requests because frontend applications often send JSON payloads, Authorization headers and HTTP methods such as PUT, PATCH or DELETE. Properly handling OPTIONS requests is therefore an essential part of API development.
Preflight Requests Only Apply in Browsers
Preflight requests are a browser feature. Server-side applications, backend services and API testing tools such as Postman or curl do not automatically perform browser CORS checks. This is why an API may work perfectly in Postman while failing inside a web application due to CORS configuration.
| Client | Preflight Requests |
|---|---|
| Web browser | Yes |
| Postman | No |
| curl | No |
| Backend application | No |
Preflight Does Not Replace Security
A preflight request only determines whether the browser may send a cross-origin request. It does not authenticate users, authorize actions or validate request data. Even after a successful preflight, the server must still perform its normal authentication, authorization and input validation checks.
Reducing Unnecessary Preflight Requests
Although preflight requests are an important security feature, unnecessary preflight traffic can increase latency. Developers can often reduce the number of preflight requests by avoiding unnecessary custom headers, using standard request formats where appropriate and allowing browsers to cache successful preflight responses.
Best Practices
- Always support HTTP OPTIONS for endpoints that require CORS.
- Return complete and accurate CORS response headers.
- Use Access-Control-Max-Age to reduce repeated preflight requests when appropriate.
- Allow only trusted origins instead of enabling unrestricted access.
- Test CORS behavior using real browsers during development.
- Review browser developer tools when debugging CORS issues.
Frequently Asked Questions
What is a preflight request?
A preflight request is an automatic HTTP OPTIONS request sent by a browser before certain cross-origin requests to determine whether the server allows the planned request under its CORS policy.
Why does the browser send an OPTIONS request?
The OPTIONS request asks the server whether the requested HTTP method, headers and origin are permitted before the browser sends the actual cross-origin request.
Do all cross-origin requests trigger a preflight request?
No. Simple requests that meet the browser's CORS requirements are sent directly. Preflight requests are required only for more complex requests, such as those using certain HTTP methods or custom headers.
Why does my API work in Postman but fail in the browser?
Postman does not enforce browser CORS rules or perform automatic preflight requests. Browsers apply the Same-Origin Policy and require proper CORS headers before exposing cross-origin responses to JavaScript.
Can I disable preflight requests?
No. Browsers automatically determine when a preflight request is necessary according to the CORS specification. Developers should configure their servers correctly rather than attempting to disable the mechanism.
Helpful HTTP Tools
An HTTP Request Builder helps construct requests for CORS testing, a CORS Header Generator creates valid Access-Control-* response headers, an HTTP Header Viewer displays both request and response headers during debugging, an HTTP Response Formatter improves the readability of API responses, and an HTTP Header Generator assists in building complete HTTP requests and responses for development and testing.
Conclusion
Preflight requests are a fundamental part of the browser's CORS security model. By sending an automatic HTTP OPTIONS request before certain cross-origin operations, browsers ensure that servers explicitly approve potentially sensitive requests before they are executed. Understanding when preflight requests occur, which headers are involved and how browsers evaluate server responses enables developers to configure secure APIs, troubleshoot CORS issues more efficiently and build reliable cross-origin web applications.