D'où vient la limite de taille des cookies de 4096 octets

Quelle est la limite de taille des cookies ?

Les navigateurs appliquent une limite de taille des cookies de 4096 octets mesurée sur le nom et la valeur, et un plafond distinct de 1024 octets sur chaque valeur d'attribut prise séparément. Aucun de ces deux chiffres n'est une suggestion dans les navigateurs actuels, et aucun ne veut tout à fait dire ce que les anciennes spécifications lui faisaient dire. Le chiffre que tout le monde cite comme "4KB per cookie" a commencé sa vie comme un plancher que les agents utilisateurs devaient garantir et a fini en plafond qu'ils sont tenus d'appliquer, et ce basculement a changé ce que l'on compte.

Si les cookies comme mécanisme vous sont nouveaux, commencez par le guide des cookies de navigateur pour débutants et revenez ici pour les chiffres.

Que demandent réellement les spécifications ?

Trois documents disent trois choses différentes, et les trois sont vivants sur le web en ce moment.

La RFC 2965, la spécification Set-Cookie2 de 1999, ouvre sa section 5.3 sur l'inverse d'une limite : "In general, user agents' cookie support should have no fixed limits." Elle nomme ensuite des minimums à garantir : "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)," et "at least 20 cookies per unique host or domain name."

La RFC 6265, le remplacement de 2011, garde le même cadrage à la section 6.1. Les agents utilisateurs à usage général SHOULD fournir "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" et "At least 3000 cookies total." Regardez la parenthèse : les attributs sont à l'intérieur des 4096.

La RFC 6265bis, brouillon 22 du 1er décembre 2025, qui rend la RFC 6265 obsolète si elle est approuvée, déplace le chiffre dans l'algorithme d'analyse obligatoire et change ce qu'il mesure. L'étape 5 de l'analyseur Set-Cookie se lit : "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." Les attributs n'y sont plus comptés. Ils reçoivent leur propre règle à l'étape 6 : "If the attribute-value is longer than 1024 octets, ignore the cookie-av string and return to Step 1 of this algorithm." La section 6.1 du brouillon a laissé tomber en conséquence la puce 4096, ne gardant que les décomptes par domaine et au total, avec cette note : "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."

Du coup la page document.cookie de MDN, qui dit encore à ses lecteurs que la 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," et le guide des cookies de MDN lui-même, qui annonce "a maximum size per cookie (usually 4KB)," sont exacts tous les deux, sur des spécifications différentes. Les navigateurs, eux, implémentent la troisième.

Qu'applique chaque navigateur ?

Chromium et Firefox ont tous deux atterri sur les chiffres de la RFC 6265bis, et tous deux les posent dans le code source sous forme de constantes nommées.

Chromium déclare les deux limites d'octets dans net/cookies/parsed_cookie.h, chacune avec son propre commentaire :

// 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 déclare la limite d'octets dans netwerk/cookie/CookieValidation.cpp sous la forme constexpr uint32_t kMaxBytesPerCookie = 4096; et l'applique dans une fonction dont le commentaire cite encore la spécification d'il y a deux révisions :

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;

Le plafond d'attribut vit à part dans netwerk/cookie/CookieParser.cpp sous la forme constexpr uint64_t ATTRIBUTE_MAX_LENGTH = 1024;.

Safari est le trou. Apple ne publie aucune limite d'octets par cookie, et le billet de WebKit sur sa politique de stockage place explicitement les cookies hors du système de quota qu'il décrit, en précisant que "cookies and HTTP cache are currently not subject to the policy below" et que "they are not bounded by quota." Safari impose bien d'autres restrictions sur les cookies, dont le plafond de sept jours sur les cookies écrits par script, mais un plafond de taille documenté n'en fait pas partie. Dimensionnez sur les chiffres de Chromium et de Gecko et vous êtes tranquille partout.

Que se passe-t-il quand un cookie dépasse la limite ?

Le cookie est jeté en entier. Il n'est jamais tronqué, et le serveur n'en est jamais informé. La RFC 2965 a couché la règle par écrit en 1999 et elle n'a pas bougé : "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." La RFC 6265bis dit la même chose en langage d'analyseur, en demandant à l'agent utilisateur de "abort this algorithm and ignore the set-cookie-string entirely."

Comme l'échec est silencieux au niveau HTTP, le seul signal se trouve dans la console du navigateur, et Firefox est le moteur qui vous en donne un exploitable. Son fichier de chaînes necko.properties porte le texte exact :

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

Un attribut trop gros produit un message différent et bien plus facile à rater, parce que le cookie lui-même est quand même posé, l'attribut en moins :

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.

Ce second cas est le bug le plus vicieux. Une valeur Path ou Domain de plus de 1024 octets ne tue pas le cookie, elle change sa portée, donc le cookie existe mais cesse d'être envoyé là où vous l'attendiez.

Combien de cookies un domaine peut-il garder ?

Chromium en autorise 180 par domaine et en expulse 30 à la fois. Les constantes de net/cookies/cookie_monster.cc sont kDomainMaxCookies = 180, kDomainPurgeCookies = 30, kMaxCookies = 3300 et kPurgeCookies = 300. L'en-tête résume la politique en une phrase : "When the number of cookies gets to k{Domain,}MaxCookies purge down to k{Domain,}MaxCookies - k{Domain,}PurgeCookies." Il précise aussi comment les domaines enregistrables se partagent le budget : "the maximum number of cookies allowed for google.com and all of its subdomains will be 150-180."

Firefox arrive aux deux mêmes chiffres en les déclarant directement. netwerk/cookie/CookieCommons.h fixe kMaxCookiesPerHost = 180, kCookieQuotaPerHost = 150 et kMaxNumberOfCookies = 3000. Les deux moteurs admettent donc 180 cookies par domaine enregistrable et retombent à 150 en cas de débordement, et ils ne diffèrent que sur le plafond global, 3300 chez Chromium contre 3000 chez Firefox.

Les cookies partitionnés reçoivent leur propre budget par-dessus. Les constantes kPerPartitionDomainMaxCookies = 180 et kPerPartitionDomainMaxCookieBytes = 10240 de Chromium plafonnent ce qu'un site embarqué peut stocker dans une partition, et le plafond d'octets mord le premier pour la plupart des intégrations. Cette interaction est traitée dans comment fonctionnent les cookies partitionnés CHIPS.

Les deux moteurs expulsent, ce qui veut dire qu'un cookie posé avec succès peut disparaître plus tard sans qu'une seule ligne de votre code ne tourne. La RFC 6265bis le dit sans détour : les agents utilisateurs "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)."

Pourquoi l'en-tête de requête Cookie touche-t-il un autre plafond ?

Chaque cookie dans la portée est concaténé dans un seul en-tête de requête Cookie sur chaque requête correspondante, et c'est le serveur, pas le navigateur, qui fixe la limite là-dessus. La section 4.2.1 de la RFC 6265bis met un chiffre dessus : "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."

Deux cookies de 4096 octets sont chacun parfaitement légaux et remplissent ensemble un en-tête de 8192 octets, avant la ligne de requête et avant tout autre en-tête. Ce qui vous sauve un peu, c'est que le trajet retour transporte moins que l'aller : "Notice that the cookie attributes are not returned." L'en-tête de requête ne contient que des paires nom et valeur, donc Expires, Path, Domain et SameSite vous coûtent du stockage mais pas de la bande passante.

Le calcul qui vaut la peine d'être fait avant d'expédier un gros cookie est celui du côté requête :

octets d'en-tête = somme sur les cookies dans la portée de (longueur du nom + 1 + longueur de la valeur + 2)

Douze cookies pesant en moyenne 600 octets de nom plus valeur posent à peu près 7 200 octets sur chaque requête vers ce domaine, chaque requête d'image et de script comprise. Un site qui en arrive là gagne en général à stocker une clé opaque dans le cookie et la charge utile côté serveur, ou à basculer vers une approche qui ne pose aucun cookie, comme le fait le tracking sans cookie. Si vous en êtes encore à décider quels cookies vous appartiennent, cookies first-party et third-party trace la ligne.

Foire aux questions

La limite de 4096 octets inclut-elle les attributs du cookie ?

Cela dépend de la spécification que vous lisez, et les navigateurs actuels suivent la plus récente. La RFC 6265 mesurait les 4096 "as the sum of the length of the cookie's name, value, and attributes." La RFC 6265bis ne compte que "the name string and the value string," et donne à chaque valeur d'attribut une limite séparée de 1024 octets, ce qu'implémentent Chromium et Firefox.

Qu'arrive-t-il à un cookie trop gros ?

Le navigateur le jette entièrement et le serveur ne reçoit aucune erreur. La RFC 2965 exigeait qu'un cookie non stockable "MUST be discarded, not truncated," et la RFC 6265bis dit à l'analyseur de "abort this algorithm and ignore the set-cookie-string entirely." Firefox écrit Cookie "name" is invalid because its size is too big dans la console ; la réponse réseau, elle, a tout l'air d'une réussite.

Combien de cookies un seul domaine peut-il poser ?

180 chez Chromium comme chez Firefox, avec retour à 150 en cas de débordement. Le kDomainMaxCookies de Chromium vaut 180 et son kDomainPurgeCookies vaut 30 ; le kMaxCookiesPerHost de Firefox vaut 180 et son kCookieQuotaPerHost vaut 150. Les sous-domaines partagent le budget du domaine enregistrable au lieu d'avoir le leur.

La limite se mesure-t-elle en caractères ou en octets ?

En octets. La RFC 6265bis spécifie 4096 octets, Chromium type sa constante en size_t sur la chaîne de cookie sérialisée, et les valeurs non ASCII sont encodées en pourcentage ou en UTF-8 avant la vérification. Une valeur faite de caractères multi-octets consomme sa longueur encodée, pas son nombre de caractères.

La limite s'applique-t-elle à tout l'en-tête de requête Cookie ?

Non. La règle des 4096 octets s'applique par cookie, au moment du stockage. L'en-tête Cookie combiné est borné par le serveur à la place, et la RFC 6265bis note que "many popular implementations have default limits of 8192 octets," ce que deux cookies de taille maximale atteignent à eux seuls.

Que stocker à la place d'un gros cookie ?

Stockez un identifiant opaque de quelques dizaines d'octets et gardez la charge utile côté serveur, indexée par cet identifiant. Le cookie coûte alors la même chose sur chaque requête quel que soit le volume d'état qu'il désigne, et cet état n'est plus lisible ni modifiable par quoi que ce soit qui tourne dans la page.

Safari applique-t-il une limite de taille de cookie comme Chrome et Firefox ?

Safari, ou WebKit, ne publie aucune limite en octets documentée pour les cookies. Le billet de WebKit sur sa politique de stockage exclut explicitement les cookies du système de quota et précise qu'ils sont "not bounded by quota". Safari impose d'autres règles aux cookies, comme le plafond de sept jours sur les cookies écrits par script, mais un plafond de taille n'en fait pas partie. En se calant sur les chiffres de Chromium et Gecko, on reste dans les clous partout.

Pourquoi Chromium autorise-t-il plus de cookies au total que Firefox ?

Chromium plafonne le total à 3300 (kMaxCookies), Firefox à 3000 (kMaxNumberOfCookies). Les deux moteurs s'accordent sur les chiffres par domaine, 180 autorisés et 150 après purge, l'écart n'apparaît donc que sur le plafond global. La RFC 6265 demande au moins 3000 cookies au total et 6265bis cite 3000 à titre d'exemple, les moteurs divergent donc.

Les cookies partitionnés ont-ils une limite de taille à part ?

Chromium ajoute un budget par partition pour les cookies CHIPS, en plus de la limite habituelle par domaine. kPerPartitionDomainMaxCookies vaut 180, et kPerPartitionDomainMaxCookieBytes plafonne la partition à 10240 octets, une limite qui, pour la plupart des contenus intégrés, se déclenche avant le compte de cookies. C'est distinct de la limite de 4096 octets par cookie, elle borne ce qu'un site intégré peut stocker au total dans une partition.

Un cookie survit-il à un attribut trop long ?

Un nom plus une valeur trop longs font supprimer le cookie en entier, mais un attribut trop long ne le fait pas. Firefox journalise un message indiquant que l'attribut a été rejeté pour sa taille, et le cookie est quand même posé, sans cet attribut. Une valeur Path ou Domain de plus de 1024 octets change alors la portée du cookie plutôt que de le supprimer, il continue d'exister mais cesse d'être envoyé là où on l'attendait.