HTTP 431 Request Header Fields Too Large
HTTP 431 Request Header Fields Too Large, defined in RFC 6585, is returned when the server refuses a request because the header section — either a single field or the total — is too big. A frequent cause is an oversized or accumulated cookie. The server can indicate which header caused the problem so the client can reduce it.
What 431 means
431 Request Header Fields Too Large, from RFC 6585, lets a server refuse a request when its header fields are too large. This can be triggered by a single oversized field — such as one very long cookie or a huge custom header — or by the cumulative size of all headers exceeding the server's configured limit.
RFC 6585 notes the response can indicate which header field caused the rejection, helping the client identify what to trim.
Common causes and fixes
The most common real-world cause is cookie bloat: many cookies, or a few large ones, accumulating for a domain until the Cookie header crosses the limit. Long bearer tokens or verbose custom headers can do the same on APIs.
Fixes are to reduce header size — prune or shrink cookies, shorten tokens, drop unnecessary custom headers — or to raise the server's header-size limit where appropriate. Lean-header clients like search crawlers rarely hit this, so a 431 usually points to client-side header accumulation.
- Triggered by one oversized field or total header size
- Most common cause: accumulated/oversized cookies
- Fix: trim headers/cookies or raise the server limit
How it appears in analytics and logs
A 431 means the request's headers exceeded the server's limit. It often traces to large cookies built up over time. It affects any client carrying those headers, including browsers, more than typical crawlers, which send lean headers.
Diagnostic use case
Diagnose 431s caused by bloated cookies or accumulated headers, and reduce header size or raise the server's header limit to restore access.
What WebmasterID can help detect
WebmasterID surfaces status codes for traffic, helping you detect 431s that point to cookie or header bloat affecting real clients' access to your pages.
Common mistakes
- Letting cookies accumulate for a domain until the Cookie header exceeds the limit.
- Raising the app's header limit but not the front proxy's, so 431 persists.
- Assuming a crawler caused 431 when lean-header bots rarely trigger it.
Privacy and accuracy notes
A 431 concerns header size, not header contents. WebmasterID records the status without storing cookie values or other header data tied to a visitor.
Related pages
- HTTP 400 Bad Request for crawlers
400 Bad Request means the server refused to process the request because it appeared malformed — bad syntax, invalid headers, or a request the server cannot interpret. Seeing 400s for crawlers usually points at malformed URLs, encoding issues, or a misbehaving edge layer rather than the crawler itself.
- HTTP 414 URI Too Long
HTTP 414 URI Too Long is returned when the request-target URI is longer than the server is willing to interpret. It often comes from query strings that have grown unbounded — for example a GET form that should have been a POST, parameters appended in a loop, or a redirect that keeps stacking parameters. For crawling, over-long parameterised URLs can both waste crawl budget and trip 414s.
- HTTP 413 Content Too Large
HTTP 413 Content Too Large — renamed from Payload Too Large in RFC 9110 — is returned when the request body is larger than the server is willing or able to process. It commonly appears on upload endpoints and large POST bodies. The server may include a Retry-After header if the condition is temporary. Read-only crawler GETs carry no body, so this status does not affect normal page indexing.
- Website observability
Detect header-size errors affecting client access to your pages, recorded server-side.
Sources and verification notes
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.