431 Request Header Fields Too Large 4xx

What does 431 mean?

A 431 Request Header Fields Too Large response means the total size of the request's headers — either all of them combined, or one specific header — exceeds what the server is willing to process. While 413 is about the request body and 414 is about the URL, 431 is specifically about headers: things like Cookie, Authorization, User-Agent, custom application headers, and so on.

This code is standardized but relatively uncommon in everyday development — most requests have modest header sizes. It becomes relevant in scenarios where headers accumulate unexpectedly large amounts of data, most notably cookies.

How a 431 behaves

• It can carry a body explaining the issue, though space is obviously limited if headers are also part of the problem
• It's most commonly triggered by oversized cookies — cookies are sent as part of the Cookie header on every request to a domain, and if an application stores increasingly large amounts of data in cookies over time, this header can grow until it exceeds server limits
• Different servers have different header-size limits — similar to 413/414, this can vary across web servers, proxies, and CDNs, with the smallest limit in the chain determining when 431 appears
• It can apply to a single header or the total of all headers — some server configurations limit individual header sizes, others limit the cumulative total, and 431 can result from either

Common causes

If you're building the API or website:

• Your application stores too much data in cookies — session data, feature flags, tracking information, or other state accumulates in cookies over a user's session until the Cookie header becomes too large
• A bug causes cookies to be set repeatedly without old ones being cleared, leading to cookie bloat over time
• Authentication tokens (especially JWTs with large payloads) stored in headers grow larger than expected, particularly if a token contains an extensive set of claims/permissions

If you're calling an API:

• You're including an unusually large authentication token or custom header in your requests
• Accumulated cookies from a long-lived session (in browser-based testing/automation) have grown beyond typical limits

If you're a website visitor:

• You've been using a site for a long time without clearing cookies, and the site has accumulated an unusually large amount of cookie data for its domain
• A site has a bug causing excessive cookie growth, and clearing your cookies for that site resolves the issue (temporarily, until the bug causes it to recur)

How to fix it

As an API/website builder:

• Audit what's being stored in cookies — session identifiers should typically be small (an ID referencing server-side session data), not large blobs of application state
• If using JWTs or similar tokens in headers, keep the payload minimal — avoid embedding large amounts of data directly in tokens that get sent with every request
• Implement cookie cleanup — ensure old/unused cookies are properly expired and removed rather than accumulating indefinitely
• Consider server-side session storage (with just a small session ID cookie) instead of client-side cookie-based state for anything beyond minimal data

As an API consumer:

• Check the size of headers (especially Cookie and Authorization) you're sending — if a token or cookie has grown unexpectedly large, investigate why
• For browser-based testing/automation, periodically clear cookies to avoid accumulation across many test runs

As a website visitor:

• Clear cookies for the site experiencing this issue — this often resolves 431 caused by cookie bloat, at least temporarily
• If the issue recurs quickly after clearing cookies, it likely indicates a bug on the site's end that re-accumulates cookie data rapidly

431 vs 413 vs 414

Real-world examples

Cookie bloat is the most commonly cited real-world cause of 431 — applications that progressively add more data to cookies over a user's session (tracking IDs, feature flags, A/B test assignments, partial form state, etc.) without cleaning up old entries can eventually produce a Cookie header large enough to trigger 431, often appearing only for long-tenured users/sessions rather than new visitors, making it tricky to reproduce and diagnose. JWT-based authentication systems that embed extensive claims (roles, permissions lists, profile data) directly in the token can produce Authorization headers large enough to contribute to 431, particularly if the token is sent on every request including for static assets.

SEO implications

431 could theoretically affect crawlability if a site's cookie-setting behavior somehow caused excessively large headers for crawler requests, but this is unusual — search engine crawlers typically don't accumulate session cookies the way logged-in user sessions do, making 431 rarely an SEO concern in practice.

FAQ

What's the most common cause of 431?

Oversized cookies — specifically, a Cookie header that's grown too large due to an application storing increasing amounts of data in cookies over time without proper cleanup.

How do I fix 431 as a website visitor?

Clear cookies for the affected site. If the problem returns quickly, it likely indicates the site has a bug causing rapid cookie accumulation, which would need to be fixed on the site's end.

What's the difference between 431, 413, and 414?

413 is about the request body being too large. 414 is about the URL being too long. 431 is specifically about the request's headers (most commonly cookies) being too large — three different parts of a request, each with their own size-limit error code.

Should I store large amounts of data in cookies?

Generally no — cookies are sent with every request to a domain, so large cookies add overhead to every single request, not just the one that set them. Server-side session storage (with a small session-ID cookie) is generally preferable for anything beyond minimal data.

Can 431 happen due to custom application headers, not just cookies?

Yes — while cookies are the most common cause, any header (custom application headers, large authentication tokens, etc.) contributing to an overly large total header size can trigger 431, depending on whether the server's limit applies per-header or to the cumulative total.

Fun fact

431 was standardized in the same 2014-era wave of "modern problem" status codes (alongside 428 and 429 from 2012's RFC 6585, and 431 itself from a related 2014 RFC) — together these represent HTTP's relatively recent acknowledgment that headers, cookies, and request metadata had grown from a few simple lines in early HTTP/1.0 requests into a substantial and sometimes problematic part of modern web traffic, to the point of needing their own dedicated "too large" error.