Da dove arriva il limite di dimensione dei cookie di 4096 byte

Qual è il limite di dimensione dei cookie?

I browser impongono un limite di 4096 byte per cookie, misurato sommando nome e valore, e un tetto separato di 1024 byte per il valore di ogni singolo attributo. Nei browser attuali nessuno dei due numeri è un semplice suggerimento, e nessuno dei due significa del tutto ciò che dicevano le vecchie specifiche. La cifra che tutti citano come "4KB per cookie" è nata come soglia minima che gli user agent dovevano garantire ed è diventata un tetto che sono obbligati a far rispettare. Il passaggio ha cambiato anche ciò che viene conteggiato.

Se i cookie come meccanismo sono nuovi per te, parti dalla guida ai cookie del browser per principianti e poi torna qui per i numeri.

Cosa richiedono davvero le specifiche?

Tre documenti dicono tre cose diverse, e tutti e tre sono ancora vivi sul web.

La RFC 2965, la specifica Set-Cookie2 del 1999, apre la sezione 5.3 con l'opposto di un limite: "In generale, il supporto ai cookie degli user agent non dovrebbe avere limiti fissi." Poi indica dei minimi da garantire: "almeno 300 cookie", "almeno 4096 byte per cookie (misurati in base ai caratteri che compongono il non-terminale cookie nella descrizione della sintassi dell'header Set-Cookie2, e come ricevuti nell'header Set-Cookie2)" e "almeno 20 cookie per ogni host o nome di dominio univoco".

La RFC 6265, che l'ha sostituita nel 2011, mantiene la stessa impostazione nella sezione 6.1. Gli user agent generici DOVREBBERO offrire "almeno 4096 byte per cookie (misurati come somma della lunghezza di nome, valore e attributi del cookie)", più "almeno 50 cookie per dominio" e "almeno 3000 cookie in totale". Nota la parentesi: gli attributi rientrano nei 4096.

La RFC 6265bis, bozza 22 del 1° dicembre 2025, che se approvata renderà obsoleta la RFC 6265, sposta il numero nell'algoritmo di parsing obbligatorio e cambia ciò che misura. Il passaggio 5 del parser di Set-Cookie recita: "Se la somma delle lunghezze della stringa del nome e della stringa del valore supera i 4096 ottetti, interrompi questo algoritmo e ignora del tutto la set-cookie-string." Qui gli attributi non vengono più contati. Hanno una regola a parte nel passaggio 6: "Se il valore dell'attributo è più lungo di 1024 ottetti, ignora la stringa cookie-av e torna al passaggio 1 di questo algoritmo." La sezione 6.1 della bozza ha di conseguenza eliminato il punto sui 4096, mantenendo solo i conteggi per dominio e totali, con la nota che "un limite al numero massimo di cookie limita anche la dimensione totale dei cookie memorizzati, a causa dei limiti di lunghezza che DEVONO essere applicati".

Quindi la pagina MDN su document.cookie, che ancora dice ai lettori che la RFC 2965 "specifica che non dovrebbe esserci una lunghezza massima per la chiave o il valore di un cookie, e incoraggia le implementazioni a supportare cookie di dimensioni arbitrarie", e la guida ai cookie di MDN, che parla di "una dimensione massima per cookie (di solito 4KB)", sono entrambe corrette, ma riguardano specifiche diverse. I browser implementano la terza.

Cosa applica ogni browser?

Chromium e Firefox sono approdati entrambi ai numeri della RFC 6265bis, e li hanno messi nel codice sorgente come costanti con nome.

Chromium dichiara entrambi i limiti in byte in net/cookies/parsed_cookie.h, ciascuno con il proprio commento:

// 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 dichiara il limite in byte in netwerk/cookie/CookieValidation.cpp come constexpr uint32_t kMaxBytesPerCookie = 4096; e lo applica in una funzione il cui commento cita ancora la specifica di due revisioni fa:

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;

Il tetto per gli attributi si trova a parte in netwerk/cookie/CookieParser.cpp come constexpr uint64_t ATTRIBUTE_MAX_LENGTH = 1024;.

Safari è il vuoto. Apple non pubblica alcun limite in byte per cookie, e il post di WebKit sulla policy di archiviazione esclude esplicitamente i cookie dal sistema di quote che descrive, dichiarando che "i cookie e la cache HTTP al momento non sono soggetti alla policy seguente" e che "non sono limitati da una quota". Safari impone altre restrizioni sui cookie, tra cui il limite di sette giorni per i cookie scritti via script, ma un tetto di dimensione documentato non è tra queste. Se ti basi sui numeri di Chromium e Gecko, sei al sicuro ovunque.

Cosa succede quando un cookie supera il limite?

Il cookie viene scartato per intero. Non viene mai troncato, e il server non viene mai avvisato. La RFC 2965 ha messo per iscritto la regola nel 1999 e da allora non è cambiata: "Le informazioni in un header di risposta Set-Cookie2 DEVONO essere conservate per intero. Se per qualche motivo non c'è spazio sufficiente per memorizzare il cookie, DEVE essere scartato, non troncato." La RFC 6265bis dice la stessa cosa nel linguaggio del parser, istruendo lo user agent a "interrompere questo algoritmo e ignorare del tutto la set-cookie-string".

Poiché l'errore è silenzioso a livello HTTP, l'unico segnale compare nella console del browser, e Firefox è il motore che te ne dà uno utilizzabile. Il suo file di stringhe necko.properties contiene il testo esatto:

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

Un attributo troppo grande produce un messaggio diverso e più facile da perdere, perché il cookie viene comunque impostato, solo senza quell'attributo:

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.

Questo secondo caso è il bug più insidioso. Un valore di Path o Domain oltre i 1024 byte non uccide il cookie, ne cambia l'ambito, quindi il cookie esiste ma smette di essere inviato dove te lo aspettavi.

Quanti cookie può conservare un singolo dominio?

Chromium ne consente 180 per dominio e ne elimina 30 alla volta. Le costanti in net/cookies/cookie_monster.cc sono kDomainMaxCookies = 180, kDomainPurgeCookies = 30, kMaxCookies = 3300 e kPurgeCookies = 300. L'header spiega la regola in una frase: "When the number of cookies gets to k{Domain,}MaxCookies purge down to k{Domain,}MaxCookies - k{Domain,}PurgeCookies." Chiarisce anche come i domini registrabili si dividono il budget: "the maximum number of cookies allowed for google.com and all of its subdomains will be 150-180."

Firefox arriva agli stessi due numeri dichiarandoli direttamente. netwerk/cookie/CookieCommons.h imposta kMaxCookiesPerHost = 180, kCookieQuotaPerHost = 150 e kMaxNumberOfCookies = 3000. Entrambi i motori accettano quindi 180 cookie per dominio registrabile e scendono a 150 quando il limite viene superato. Si distinguono solo per il tetto globale, 3300 in Chromium contro 3000 in Firefox.

I cookie partizionati hanno un budget a parte, che si somma agli altri. In Chromium kPerPartitionDomainMaxCookies = 180 e kPerPartitionDomainMaxCookieBytes = 10240 limitano ciò che un singolo sito incorporato può salvare in una partizione, e nella maggior parte degli embed il limite in byte scatta per primo. Ne parliamo in come funzionano i cookie partizionati CHIPS.

Entrambi i motori eliminano cookie, quindi un cookie impostato con successo può sparire più tardi senza che giri alcun tuo codice. La RFC 6265bis lo dice chiaramente: gli user agent "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)."

Perché l'header di richiesta Cookie incontra un tetto diverso?

Ogni cookie nell'ambito viene concatenato in un unico header di richiesta Cookie a ogni richiesta corrispondente, e il limite lo decide il server, non il browser. La sezione 4.2.1 della RFC 6265bis dà il numero: "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."

Due cookie da 4096 byte sono ciascuno legittimo, ma insieme riempiono un header da 8192 byte, prima ancora della riga di richiesta o di qualsiasi altro header. Ti aiuta un po' il fatto che il viaggio di ritorno porta meno dati dell'andata: "Notice that the cookie attributes are not returned." L'header di richiesta contiene solo coppie nome e valore, quindi Expires, Path, Domain e SameSite pesano sull'archiviazione ma non sulla banda.

Prima di pubblicare un cookie grande conviene fare il conto lato richiesta:

byte dell'header = somma, per tutti i cookie nell'ambito, di (lunghezza del nome + 1 + lunghezza del valore + 2)

Dodici cookie con una media di 600 byte tra nome e valore mettono circa 7.200 byte su ogni singola richiesta verso quel dominio, comprese le richieste di immagini e script. Un sito che arriva a questo punto di solito sta meglio salvando nel cookie una chiave opaca e tenendo il contenuto sul server, oppure passando a un approccio che non imposta alcun cookie, come fa il tracciamento senza cookie. Se non hai ancora deciso quali cookie spettano a te, cookie di prima e di terza parte traccia questa linea.

Domande frequenti

Il limite di 4096 byte include gli attributi del cookie?

Dipende da quale specifica leggi, e i browser attuali seguono la più recente. La RFC 6265 misurava 4096 "as the sum of the length of the cookie's name, value, and attributes." La RFC 6265bis conta solo "the name string and the value string" e dà a ogni valore di attributo un limite separato di 1024 ottetti, che è ciò che implementano Chromium e Firefox.

Che cosa succede a un cookie troppo grande?

Il browser lo scarta del tutto e il server non riceve alcun errore. La RFC 2965 imponeva che un cookie non memorizzabile "MUST be discarded, not truncated", e la RFC 6265bis dice al parser di "abort this algorithm and ignore the set-cookie-string entirely." Firefox scrive nella console Cookie "name" is invalid because its size is too big, mentre la risposta di rete sembra andata a buon fine.

Quanti cookie può impostare un dominio?

180 sia in Chromium sia in Firefox, con ritorno a 150 in caso di superamento. In Chromium kDomainMaxCookies vale 180 e kDomainPurgeCookies vale 30. In Firefox kMaxCookiesPerHost vale 180 e kCookieQuotaPerHost vale 150. I sottodomini condividono il budget del dominio registrabile invece di averne uno proprio.

Il limite si misura in caratteri o in byte?

In byte. La RFC 6265bis specifica 4096 ottetti, Chromium dichiara la sua costante come size_t sulla stringa del cookie serializzata, e i valori non ASCII vengono codificati in percent-encoding o in UTF-8 prima del controllo. Un valore fatto di caratteri multibyte consuma la lunghezza della sua codifica, non il numero di caratteri.

Il limite vale per l'intero header di richiesta Cookie?

No. La regola dei 4096 byte vale per ogni cookie al momento del salvataggio. L'header Cookie complessivo è invece limitato dal server, e la RFC 6265bis osserva che "many popular implementations have default limits of 8192 octets", soglia che due cookie di dimensione massima raggiungono da soli.

Che cosa conviene salvare al posto di un cookie grande?

Salva un identificatore opaco di poche decine di byte e tieni il contenuto sul server, indicizzato da quell'identificatore. Il cookie costa così lo stesso a ogni richiesta, qualunque sia la quantità di stato a cui punta, e lo stato non è più leggibile né modificabile da ciò che gira nella pagina.

Safari applica un limite di dimensione ai cookie come Chrome e Firefox?

Safari, ovvero WebKit, non pubblica alcun limite in byte documentato per i cookie. L'articolo di WebKit sulla politica di archiviazione esclude esplicitamente i cookie dal sistema di quote, affermando che sono "not bounded by quota." Safari applica altre regole sui cookie, tra cui il tetto di sette giorni per i cookie scritti da script, ma un limite di dimensione non è tra queste. Se ti regoli sui numeri di Chromium e Gecko, sei al sicuro ovunque.

Perché Chromium consente più cookie totali di Firefox?

Chromium fissa il totale a 3300 (kMaxCookies), Firefox a 3000 (kMaxNumberOfCookies). Entrambi i motori concordano sui valori per dominio, 180 consentiti e 150 dopo l'eliminazione, quindi la differenza emerge solo nel tetto globale. La RFC 6265 chiede almeno 3000 cookie in totale e la 6265bis cita 3000 come esempio, quindi i motori possono differire.

I cookie partizionati hanno un limite di dimensione separato?

Chromium aggiunge un budget per partizione ai cookie CHIPS, oltre al normale limite per dominio. kPerPartitionDomainMaxCookies vale 180, e kPerPartitionDomainMaxCookieBytes limita la partizione a 10240 byte, un limite che nella maggior parte degli embed scatta prima di quello sul numero di cookie. Questo limite è distinto da quello di 4096 byte per cookie e restringe ciò che un singolo sito incorporato può salvare, con tutti i suoi cookie, in una partizione.

Un cookie può sopravvivere con un valore di attributo troppo grande?

Un nome più valore troppo grande fa scartare il cookie per intero, ma un attributo troppo grande no. Firefox registra un messaggio che indica che l'attributo è stato rifiutato perché troppo grande, e il cookie viene comunque impostato, solo senza quell'attributo. Un valore di Path o Domain oltre i 1024 byte cambia l'ambito del cookie invece di eliminarlo, quindi il cookie continua a esistere ma non viene più inviato dove ti aspettavi.