Woher das Cookie-Größenlimit von 4096 Bytes stammt

Was ist das Cookie-Größenlimit?

Browser erzwingen ein Cookie-Größenlimit von 4096 Bytes, gemessen über Name und Wert, sowie eine getrennte Obergrenze von 1024 Bytes für jeden einzelnen Attributwert. Keine der beiden Zahlen ist in aktuellen Browsern ein Vorschlag, und keine bedeutet ganz das, was die älteren Spezifikationen sagten. Die Zahl, die alle als "4 KB pro Cookie" zitieren, startete als Untergrenze, die User Agents garantieren sollten, und endete als Obergrenze, die sie durchsetzen müssen, und der Wechsel hat verändert, was gezählt wird.

Wenn Cookies als Mechanismus für Sie neu sind, starten Sie mit dem Einsteigerleitfaden zu Browser-Cookies und kommen für die Zahlen zurück.

Was verlangen die Spezifikationen tatsächlich?

Drei Dokumente sagen drei verschiedene Dinge, und alle drei sind gerade jetzt im Web aktiv.

RFC 2965, die Set-Cookie2-Spezifikation von 1999, eröffnet Abschnitt 5.3 mit dem Gegenteil eines Limits: "In general, user agents' cookie support should have no fixed limits." Dann nennt sie zu garantierende Minima: "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)," und "at least 20 cookies per unique host or domain name."

RFC 6265, der Ersatz von 2011, behält dieselbe Rahmung in Abschnitt 6.1. User Agents für allgemeine Nutzung SOLLTEN bereitstellen: "At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes)," dazu "At least 50 cookies per domain" und "At least 3000 cookies total." Beachten Sie die Klammer: Attribute liegen innerhalb der 4096.

RFC 6265bis, Entwurf 22 vom 1. Dezember 2025, der RFC 6265 im Fall der Annahme ablöst, verschiebt die Zahl in den verbindlichen Parsing-Algorithmus und ändert, was sie misst. Schritt 5 des Set-Cookie-Parsers lautet: "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." Attribute werden dort nicht mehr mitgezählt. Sie bekommen ihre eigene Regel in Schritt 6: "If the attribute-value is longer than 1024 octets, ignore the cookie-av string and return to Step 1 of this algorithm." Abschnitt 6.1 des Entwurfs hat den 4096-Punkt entsprechend gestrichen und behält nur die Zahlen je Domain und insgesamt, mit dem Hinweis, dass "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."

Die document.cookie-Seite von MDN, die Lesern weiterhin sagt, 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," und MDNs eigener Cookie-Leitfaden, der von "a maximum size per cookie (usually 4KB)" spricht, sind also beide korrekt, nur zu verschiedenen Spezifikationen. Browser implementieren die dritte.

Was setzt jeder Browser durch?

Chromium und Firefox sind beide bei den Zahlen aus RFC 6265bis gelandet und legen sie im Quellcode als benannte Konstanten ab.

Chromium deklariert beide Byte-Limits in net/cookies/parsed_cookie.h, jedes mit eigenem Kommentar:

// 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 deklariert das Byte-Limit in netwerk/cookie/CookieValidation.cpp als constexpr uint32_t kMaxBytesPerCookie = 4096; und wendet es in einer Funktion an, deren Kommentar noch die Spezifikation zwei Revisionen zuvor zitiert:

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;

Der Attributdeckel liegt separat in netwerk/cookie/CookieParser.cpp als constexpr uint64_t ATTRIBUTE_MAX_LENGTH = 1024;.

Safari ist die Lücke. Apple veröffentlicht kein Byte-Limit pro Cookie, und WebKits Beitrag zur Speicherrichtlinie stellt Cookies ausdrücklich außerhalb des beschriebenen Quotensystems, mit der Aussage, dass "cookies and HTTP cache are currently not subject to the policy below" und dass "they are not bounded by quota." Safari erlegt Cookies durchaus andere Beschränkungen auf, darunter die Sieben-Tage-Grenze für per Skript gesetzte Cookies, aber eine dokumentierte Größenobergrenze gehört nicht dazu. Kalkulieren Sie mit den Zahlen von Chromium und Gecko, dann sind Sie überall auf der sicheren Seite.

Was passiert, wenn ein Cookie das Limit überschreitet?

Das Cookie wird ganz verworfen. Es wird nie gekürzt, und der Server erfährt nichts. RFC 2965 schrieb die Regel 1999 auf und sie hat sich nicht geändert: "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 sagt dasselbe in Parser-Sprache und weist den User Agent an, "abort this algorithm and ignore the set-cookie-string entirely."

Weil das Scheitern auf HTTP-Ebene stumm bleibt, ist das einzige Signal die Browserkonsole, und Firefox ist die Engine, die Ihnen ein brauchbares gibt. Seine Stringdatei necko.properties trägt den genauen Text:

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

Ein zu großes Attribut erzeugt eine andere und leichter zu übersehende Meldung, weil das Cookie selbst weiterhin gesetzt wird, nur ohne dieses Attribut:

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.

Dieser zweite Fall ist der fiesere Bug. Ein Path- oder Domain-Wert über 1024 Bytes tötet das Cookie nicht, er ändert seinen Geltungsbereich, also existiert das Cookie und wird nicht mehr dorthin gesendet, wo Sie es erwartet haben.

Wie viele Cookies darf eine Domain behalten?

Chromium erlaubt 180 je Domain und räumt 30 auf einmal ab. Die Konstanten in net/cookies/cookie_monster.cc lauten kDomainMaxCookies = 180, kDomainPurgeCookies = 30, kMaxCookies = 3300 und kPurgeCookies = 300. Der Header erklärt die Regel in einem Satz: "When the number of cookies gets to k{Domain,}MaxCookies purge down to k{Domain,}MaxCookies - k{Domain,}PurgeCookies." Er buchstabiert auch aus, wie registrierbare Domains das Budget teilen: "the maximum number of cookies allowed for google.com and all of its subdomains will be 150-180."

Firefox landet bei denselben zwei Zahlen, indem es sie direkt deklariert. netwerk/cookie/CookieCommons.h setzt kMaxCookiesPerHost = 180, kCookieQuotaPerHost = 150 und kMaxNumberOfCookies = 3000. Beide Engines lassen also 180 Cookies je registrierbarer Domain zu und fallen bei Überlauf auf 150 zurück, und sie unterscheiden sich nur bei der globalen Obergrenze, 3300 in Chromium gegen 3000 in Firefox.

Partitionierte Cookies bekommen obendrauf ihr eigenes Budget. Chromiums kPerPartitionDomainMaxCookies = 180 und kPerPartitionDomainMaxCookieBytes = 10240 deckeln, was eine eingebettete Website in einer Partition speichern kann, und für die meisten Einbettungen greift der Byte-Deckel zuerst. Dieses Zusammenspiel behandelt wie partitionierte CHIPS-Cookies funktionieren.

Beide Engines räumen ab, was bedeutet, dass ein erfolgreich gesetztes Cookie später verschwinden kann, ohne dass Code von Ihnen läuft. RFC 6265bis sagt das klar: 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)."

Warum trifft der Cookie-Request-Header eine andere Obergrenze?

Jedes Cookie im Geltungsbereich wird bei jeder passenden Anfrage zu einem einzigen Cookie-Request-Header zusammengefügt, und dort setzt der Server das Limit, nicht der Browser. RFC 6265bis, Abschnitt 4.2.1, nennt die Zahl: "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."

Zwei Cookies von 4096 Bytes sind jeweils einzeln zulässig und füllen zusammen einen Header von 8192 Bytes, noch vor der Request-Zeile und jedem weiteren Header. Etwas Entlastung bringt, dass der Rückweg weniger trägt als der Hinweg: "Notice that the cookie attributes are not returned." Der Request-Header enthält nur Paare aus Name und Wert, also kosten Expires, Path, Domain und SameSite Sie Speicher, aber keine Bandbreite.

Die Rechnung, die sich vor dem Ausliefern eines großen Cookies lohnt, ist die auf der Request-Seite:

Header-Bytes = Summe über die Cookies im Geltungsbereich von (Namenslänge + 1 + Wertlänge + 2)

Zwölf Cookies mit im Schnitt 600 Bytes Name plus Wert legen rund 7.200 Bytes auf jede einzelne Anfrage an diese Domain, einschließlich jeder Bild- und Skriptanfrage. Einer Website an diesem Punkt ist meist besser gedient, wenn sie einen undurchsichtigen Schlüssel im Cookie und die Nutzlast serverseitig speichert oder auf einen Ansatz wechselt, der gar keine Cookies setzt, wie cookieloses Tracking es tut. Wenn Sie noch entscheiden, welche Cookies überhaupt Ihre sind, zieht First-Party- und Third-Party-Cookies diese Linie.

Häufig gestellte Fragen

Umfasst das Limit von 4096 Bytes die Cookie-Attribute?

Das hängt davon ab, welche Spezifikation Sie lesen, und aktuelle Browser folgen der neueren. RFC 6265 maß 4096 "as the sum of the length of the cookie's name, value, and attributes." RFC 6265bis zählt nur "the name string and the value string" und gibt jedem Attributwert ein eigenes Limit von 1024 Oktetts, und genau das implementieren Chromium und Firefox.

Was passiert mit einem Cookie, das zu groß ist?

Der Browser verwirft es vollständig und der Server bekommt keinen Fehler. RFC 2965 verlangte, dass ein nicht speicherbares Cookie "MUST be discarded, not truncated," und RFC 6265bis weist den Parser an, "abort this algorithm and ignore the set-cookie-string entirely." Firefox schreibt Cookie "name" is invalid because its size is too big in die Konsole; die Netzwerkantwort sieht erfolgreich aus.

Wie viele Cookies darf eine Domain setzen?

180 in Chromium wie in Firefox, mit Rückfall auf 150 bei Überlauf. Chromiums kDomainMaxCookies ist 180 und sein kDomainPurgeCookies ist 30; Firefoxs kMaxCookiesPerHost ist 180 und sein kCookieQuotaPerHost ist 150. Subdomains teilen sich das Budget der registrierbaren Domain, statt ein eigenes zu bekommen.

Wird das Limit in Zeichen oder in Bytes gemessen?

In Bytes. RFC 6265bis nennt 4096 Oktetts, Chromium typisiert seine Konstante als size_t über die serialisierte Cookie-Zeichenkette, und Werte außerhalb von ASCII werden vor der Prüfung prozentcodiert oder UTF-8-codiert. Ein Wert aus Mehrbyte-Zeichen verbraucht seine codierte Länge, nicht seine Zeichenzahl.

Gilt das Limit für den gesamten Cookie-Request-Header?

Nein. Die Regel von 4096 Bytes gilt je Cookie zum Zeitpunkt des Speicherns. Der kombinierte Cookie-Header wird stattdessen vom Server begrenzt, und RFC 6265bis hält fest, dass "many popular implementations have default limits of 8192 octets," was zwei Cookies in Maximalgröße von allein erreichen.

Was sollten Sie statt eines großen Cookies speichern?

Speichern Sie eine undurchsichtige Kennung von ein paar Dutzend Bytes und halten Sie die Nutzlast serverseitig, geschlüsselt über diese Kennung. Das Cookie kostet dann bei jeder Anfrage gleich viel, egal auf wie viel Zustand es zeigt, und der Zustand selbst ist für nichts, was in der Seite läuft, mehr lesbar oder änderbar.

Setzt Safari ein Cookie-Größenlimit wie Chrome und Firefox durch?

Safari beziehungsweise WebKit veröffentlicht kein dokumentiertes Byte-Limit für Cookies. Der Beitrag von WebKit zur Storage-Policy nimmt Cookies ausdrücklich aus dem Quota-System aus und stellt fest, dass sie "not bounded by quota" sind. Safari erzwingt andere Cookie-Regeln, etwa die Sieben-Tage-Grenze für per Skript gesetzte Cookies, aber eine Größenobergrenze gehört nicht dazu. Wer sich an den Zahlen von Chromium und Gecko orientiert, ist überall auf der sicheren Seite.

Warum erlaubt Chromium mehr Cookies insgesamt als Firefox?

Chromium begrenzt die Gesamtzahl auf 3300 (kMaxCookies), Firefox auf 3000 (kMaxNumberOfCookies). Bei den Werten pro Domain stimmen beide Engines überein, 180 erlaubt und 150 nach dem Aufräumen, der Unterschied zeigt sich nur bei der globalen Obergrenze. RFC 6265 verlangt mindestens 3000 Cookies insgesamt und 6265bis nennt 3000 als Beispiel, deshalb unterscheiden sich die Engines.

Bekommen partitionierte Cookies ein eigenes Größenlimit?

Chromium legt für CHIPS-Cookies ein zusätzliches Budget pro Partition oben auf das gewöhnliche Domain-Limit. kPerPartitionDomainMaxCookies liegt bei 180, und kPerPartitionDomainMaxCookieBytes deckelt die Partition bei 10240 Bytes, ein Limit, das bei den meisten Embeds zuerst greift. Das steht getrennt vom 4096-Byte-Limit pro Cookie, es begrenzt, was eine eingebettete Seite über alle ihre Cookies hinweg in einer Partition speichern darf.

Übersteht ein Cookie ein zu langes Attribut?

Ein zu langer Name plus Wert lässt das Cookie komplett verwerfen, ein zu langes Attribut dagegen nicht. Firefox protokolliert eine Meldung, dass das Attribut wegen seiner Größe abgelehnt wurde, und das Cookie wird trotzdem gesetzt, nur ohne dieses Attribut. Ein Path- oder Domain-Wert über 1024 Bytes ändert dadurch den Geltungsbereich des Cookies, statt es zu löschen, es bleibt bestehen, wird aber nicht mehr dort gesendet, wo erwartet.