Where the Cookie Size Limit of 4096 Bytes Comes From

What is the cookie size limit?

Browsers enforce a cookie size limit of 4096 bytes measured across the name and the value, and a separate 1024 byte ceiling on each individual attribute value. Neither number is a suggestion in current browsers, and neither one means quite what the older specifications said it meant. The figure everyone quotes as "4KB per cookie" started life as a floor that user agents were asked to guarantee and ended up as a ceiling they are required to enforce, and the switch changed what gets counted.

If cookies as a mechanism are new to you, start with the beginner's guide to browser cookies and come back for the numbers.

What do the specifications actually require?

Three documents say three different things, and all three are live on the web right now.

RFC 2965, the 1999 Set-Cookie2 specification, opens section 5.3 with the opposite of a limit: "In general, user agents' cookie support should have no fixed limits." It then names minimums to guarantee: "at least 300 cookies," "at least 4096 bytes per cookie (as measured by the characters that comprise the cookie non-terminal in the syntax description of the Set-Cookie2 header, and as received in the Set-Cookie2 header)," and "at least 20 cookies per unique host or domain name."

RFC 6265, the 2011 replacement, keeps the same framing in section 6.1. General-use user agents SHOULD provide "At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes)," plus "At least 50 cookies per domain" and "At least 3000 cookies total." Note the parenthesis: attributes are inside the 4096.

RFC 6265bis, draft 22 of 1 December 2025, which obsoletes RFC 6265 if approved, moves the number into the mandatory parsing algorithm and changes what it measures. Step 5 of the Set-Cookie parser reads: "If the sum of the lengths of the name string and the value string is more than 4096 octets, abort this algorithm and ignore the set-cookie-string entirely." Attributes are no longer counted there. They get their own rule in step 6: "If the attribute-value is longer than 1024 octets, ignore the cookie-av string and return to Step 1 of this algorithm." Section 6.1 of the draft has correspondingly dropped the 4096 bullet, keeping only the per-domain and total counts, with the note that "a limit on the maximum number of cookies also limits the total size of the stored cookies, due to the length limits which MUST be enforced."

So MDN's document.cookie page, which still tells readers that RFC 2965 "specifies that there should be no maximum length of a cookie's key or value size, and encourages implementations to support arbitrarily large cookies," and MDN's own cookies guide, which says "a maximum size per cookie (usually 4KB)," are both accurate about different specifications. Browsers implement the third one.

What does each browser enforce?

Chromium and Firefox have both landed on the RFC 6265bis numbers, and both put them in the source as named constants.

Chromium declares both byte limits in net/cookies/parsed_cookie.h, each with its own comment:

// The maximum length allowed for a cookie string's name/value pair.
static const size_t kMaxCookieNamePlusValueSize = 4096;
 
// The maximum length allowed for each attribute value in a cookie string.
static const size_t kMaxCookieAttributeValueSize = 1024;

Firefox declares the byte limit in netwerk/cookie/CookieValidation.cpp as constexpr uint32_t kMaxBytesPerCookie = 4096; and applies it in a function whose comment still cites the specification two revisions back:

bool CookieValidation::CheckNameAndValueSize(const CookieStruct& aCookieData) {
  // reject cookie if it's over the size limit, per RFC2109
  return (aCookieData.name().Length() + aCookieData.value().Length()) <=
      kMaxBytesPerCookie;

The attribute cap lives separately in netwerk/cookie/CookieParser.cpp as constexpr uint64_t ATTRIBUTE_MAX_LENGTH = 1024;.

Safari is the gap. Apple publishes no per-cookie byte limit, and WebKit's storage policy post explicitly puts cookies outside the quota system it describes, stating that "cookies and HTTP cache are currently not subject to the policy below" and that "they are not bounded by quota." Safari does impose other cookie restrictions, including the seven day cap on script-written cookies, but a documented size ceiling is not among them. Budget to the Chromium and Gecko numbers and you are safe everywhere.

What happens when a cookie exceeds the limit?

The cookie is discarded whole. It is never truncated, and the server is never told. RFC 2965 wrote the rule down in 1999 and it has not changed: "The information in a Set-Cookie2 response header MUST be retained in its entirety. If for some reason there is inadequate space to store the cookie, it MUST be discarded, not truncated." RFC 6265bis says the same thing in parser language, instructing the user agent to "abort this algorithm and ignore the set-cookie-string entirely."

Because the failure is silent at the HTTP layer, the only signal is in the browser console, and Firefox is the engine that gives you a usable one. Its necko.properties string file carries the exact text:

Cookie "%1$S" is invalid because its size is too big. Max size is %2$S B.

An oversized attribute produces a different and easier-to-miss message, because the cookie itself still gets set with that attribute dropped:

The value of the attribute "%2$S" for the cookie "%1$S" has been rejected because its size is too big. Max size is %3$S B.

That second case is the nastier bug. A Path or Domain value over 1024 bytes does not kill the cookie, it changes the cookie's scope, so the cookie exists but stops being sent where you expected it.

How many cookies can one domain keep?

Chromium allows 180 per domain and evicts 30 at a time. The constants in net/cookies/cookie_monster.cc are kDomainMaxCookies = 180, kDomainPurgeCookies = 30, kMaxCookies = 3300 and kPurgeCookies = 300. The header explains the policy in one sentence: "When the number of cookies gets to k{Domain,}MaxCookies purge down to k{Domain,}MaxCookies - k{Domain,}PurgeCookies." It also spells out how registrable domains share the budget: "the maximum number of cookies allowed for google.com and all of its subdomains will be 150-180."

Firefox lands on the same two numbers by declaring them directly. netwerk/cookie/CookieCommons.h sets kMaxCookiesPerHost = 180, kCookieQuotaPerHost = 150 and kMaxNumberOfCookies = 3000. Both engines therefore admit 180 cookies per registrable domain and fall back to 150 on overflow, and they differ only on the global ceiling, 3300 in Chromium against 3000 in Firefox.

Partitioned cookies get their own budget on top. Chromium's kPerPartitionDomainMaxCookies = 180 and kPerPartitionDomainMaxCookieBytes = 10240 cap what one embedded site can store in one partition, and the byte cap binds first for most embeds. That interaction is covered in how CHIPS partitioned cookies work.

Both engines evict, which means a cookie you set successfully can vanish later without any code of yours running. RFC 6265bis states this plainly: user agents "MAY 'remove excess cookies' from the cookie store if the number of cookies sharing a domain field exceeds some implementation-defined upper bound (such as 50 cookies)."

Why does the Cookie request header hit a different ceiling?

Every cookie in scope is concatenated into one Cookie request header on every matching request, and the server, not the browser, sets the limit on that. RFC 6265bis section 4.2.1 puts the number on it: "While Section 5.4 of [HTTP] does not define a length limit for header fields it is likely that the web server's implementation does impose a limit; many popular implementations have default limits of 8192 octets. Servers SHOULD avoid setting a large number of large cookies such that the final cookie-string would exceed their header field limit. Not doing so could result in requests to the server failing."

Two 4096 byte cookies are each individually legal and together fill an 8192 byte header, before the request line or any other header. What saves you slightly is that the return trip carries less than the outbound one: "Notice that the cookie attributes are not returned." The request header contains only name and value pairs, so Expires, Path, Domain and SameSite cost you storage but not bandwidth.

The arithmetic worth doing before you ship a large cookie is the request-side one:

header bytes = sum over cookies in scope of (name length + 1 + value length + 2)

Twelve cookies averaging 600 bytes of name plus value put roughly 7,200 bytes on every single request to that domain, including every image and script request. A site that reaches that point is usually better served by storing an opaque key in the cookie and the payload server side, or by dropping to an approach that sets no cookies at all, as cookieless tracking does. If you are still deciding which cookies belong to you at all, first-party and third-party cookies draws that line.

Frequently asked questions

Does the 4096 byte limit include the cookie attributes?

It depends which specification you read, and current browsers follow the newer one. RFC 6265 measured 4096 "as the sum of the length of the cookie's name, value, and attributes." RFC 6265bis counts only "the name string and the value string," and gives each attribute value a separate 1024 octet limit, which is what Chromium and Firefox implement.

What happens to a cookie that is too large?

The browser drops it entirely and the server gets no error. RFC 2965 required that an unstorable cookie "MUST be discarded, not truncated," and RFC 6265bis tells the parser to "abort this algorithm and ignore the set-cookie-string entirely." Firefox logs Cookie "name" is invalid because its size is too big to the console; the network response looks successful.

How many cookies can one domain set?

180 in both Chromium and Firefox, falling back to 150 on overflow. Chromium's kDomainMaxCookies is 180 and its kDomainPurgeCookies is 30; Firefox's kMaxCookiesPerHost is 180 and its kCookieQuotaPerHost is 150. Subdomains share the registrable domain's budget rather than getting their own.

Is the limit measured in characters or bytes?

Bytes. RFC 6265bis specifies 4096 octets, Chromium types its constant as size_t over the serialised cookie string, and non-ASCII values are percent-encoded or UTF-8 encoded before the check. A value of multi-byte characters consumes its encoded length, not its character count.

Does the limit apply to the whole Cookie request header?

No. The 4096 byte rule applies per cookie at storage time. The combined Cookie header is bounded by the server instead, and RFC 6265bis notes that "many popular implementations have default limits of 8192 octets," which two maximum-size cookies will reach on their own.

What should you store instead of a large cookie?

Store an opaque identifier of a few dozen bytes and keep the payload server side, keyed by that identifier. The cookie then costs the same on every request regardless of how much state it points at, and the state itself is no longer readable or editable by anything running in the page.

Does Safari enforce a cookie size limit like Chrome and Firefox?

Safari, or WebKit, publishes no documented byte limit for cookies. WebKit's storage policy post explicitly excludes cookies from its quota system, stating they are "not bounded by quota." Safari does enforce other cookie rules, including the seven day cap on script-written cookies, but a size ceiling isn't among them. Budgeting to the Chromium and Gecko numbers keeps you safe everywhere.

Why does Chromium allow more total cookies than Firefox?

Chromium caps the total at 3300 (kMaxCookies), Firefox at 3000 (kMaxNumberOfCookies). Both engines agree on the per-domain figures, 180 allowed and 150 after eviction, so the gap only shows up in the global ceiling. RFC 6265 asks for at least 3000 cookies in total and 6265bis names 3000 as an example, so engines differ.

Do partitioned cookies get a separate size limit?

Chromium adds a per-partition budget for CHIPS cookies on top of the ordinary per-domain limit. kPerPartitionDomainMaxCookies is 180, and kPerPartitionDomainMaxCookieBytes caps the partition at 10240 bytes, a limit that binds before the cookie count does for most embeds. This sits apart from the 4096 byte per-cookie limit, capping what one embedded site can store across all its cookies in one partition.

Can a cookie survive with an oversized attribute value?

An oversized name plus value gets the cookie dropped whole, but an oversized attribute doesn't. Firefox logs a message saying the attribute was rejected for being too big, and the cookie still gets set, just without that attribute. A Path or Domain value over 1024 bytes changes the cookie's scope instead of deleting it, so it keeps existing but stops being sent where you expected.