Access-Control-Allow-Methods

What the header does

Access-Control-Allow-Methods is an HTTP response header used only on preflight responses. It tells the browser which HTTP methods are permitted when the actual request reaches the endpoint from another origin.

The preflight itself is always an OPTIONS request carrying an Access-Control-Request-Method header that names the intended method. The server replies with Access-Control-Allow-Methods either covering that method or not. If the method is not covered and is not safelisted, the browser abandons the actual request.

How the exchange works

When client code initiates a cross-origin request that requires preflighting, such as a DELETE call, the browser sends OPTIONS first and names the planned method in Access-Control-Request-Method.

> OPTIONS /users/42 HTTP/2
> origin: https://app.example.com
> access-control-request-method: PUT

< HTTP/2 204
< access-control-allow-origin: https://app.example.com
< access-control-allow-methods: PUT, PATCH, DELETE

# GET, HEAD and POST are always allowed, so they need no listing.
# Only methods outside the safelist must appear here.

The browser then confirms the planned method appears in Access-Control-Allow-Methods. HTTP method names are case-sensitive, so servers should emit the conventional uppercase forms such as PUT or DELETE.

GET, HEAD and POST never need listing

The Fetch standard defines GET, HEAD, and POST as CORS-safelisted methods, and they play by different rules.

• Safelisted methods are always allowed, whether or not they appear in Access-Control-Allow-Methods.
• A safelisted method never triggers a preflight on its own, as long as the request headers and content type stay within the safelists too.
• Methods outside the safelist, such as PUT, PATCH, and DELETE, always trigger a preflight and must be named in the preflight response.

Typical values

The header value is either a comma-separated list of method names or the wildcard token.

• Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS names the common REST verbs explicitly.
• Access-Control-Allow-Methods: PUT, DELETE covers only the verbs that need preflight permission for the endpoint.
• Access-Control-Allow-Methods: * permits all methods on requests without credentials.
• Use the conventional uppercase forms, because HTTP method tokens are case-sensitive.

The wildcard and credentials

The meaning of * depends on whether the request carries credentials such as cookies or HTTP authentication.

• On requests without credentials, * grants permission for all methods.
• On requests with credentials, * is treated as the literal method name *, so standard verbs are not covered.
• Credentialed requests need explicit, comma-separated method names, plus the credentials header.

The error this header resolves

When the preflight response does not cover the intended method, the browser blocks the request and logs a CORS violation. The diagnosis guide and the preflight guide cover the full debugging flow.

• The console error reads: Method <name> is not allowed by Access-Control-Allow-Methods in preflight response.
• It fires when the method is missing from the header, or when the preflight response lacks Access-Control-Allow-Methods entirely.
• The fix is handling OPTIONS correctly on the server and returning the intended method in the header.

Good questions.