TL;DR, Resposta rápida
9 min de leituraChrome e Firefox rejeitam um cookie cujo nome e valor somados passem de 4.096 bytes, e os dois limitam cada valor de atributo a 1.024 bytes. O Chromium define kMaxCookieNamePlusValueSize = 4096 e kMaxCookieAttributeValueSize = 1024; o Firefox define kMaxBytesPerCookie = 4096 e ATTRIBUTE_MAX_LENGTH = 1024. O número 4.096 nasce na RFC 2965 e na RFC 6265 como um mínimo que o navegador deveria suportar, contado entre nome, valor e atributos; a RFC 6265bis virou isso em um máximo que o navegador tem obrigação de aplicar, contado só entre nome e valor. O armazenamento por domínio é de 180 cookies nos dois motores, com expurgo de volta para 150 nos dois. Cookies grandes demais são descartados inteiros, nunca truncados.
Qual é o limite de tamanho de cookie?
Os navegadores aplicam um limite de tamanho de cookie de 4.096 bytes medido entre o nome e o valor, além de um teto separado de 1.024 bytes para cada valor de atributo. Nenhum dos dois números é sugestão nos navegadores atuais, e nenhum deles significa exatamente o que as especificações antigas diziam. A cifra que todo mundo cita como "4KB por cookie" começou a vida como um piso que os agentes de usuário deveriam garantir e terminou como um teto que eles têm obrigação de aplicar, e a virada mudou o que entra na conta.
Se cookies como mecanismo são novidade para você, comece pelo guia de cookies de navegador para iniciantes e volte aqui para os números.
O que as especificações realmente exigem?
Três documentos dizem três coisas diferentes, e os três estão no ar agora mesmo.
A RFC 2965, a especificação do Set-Cookie2 de 1999, abre a seção 5.3 com o oposto de um limite: "In general, user agents' cookie support should have no fixed limits". Em seguida ela nomeia mínimos a 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)" e "at least 20 cookies per unique host or domain name".
A RFC 6265, a substituta de 2011, mantém o mesmo enquadramento na seção 6.1. Agentes de usuário de uso geral SHOULD oferecer "At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes)", além de "At least 50 cookies per domain" e "At least 3000 cookies total". Repare no parêntese: os atributos estão dentro dos 4.096.
A RFC 6265bis, rascunho 22, de 1º de dezembro de 2025, que torna a RFC 6265 obsoleta se for aprovada, move o número para dentro do algoritmo obrigatório de parsing e muda o que ele mede. O passo 5 do parser de Set-Cookie diz: "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". Os atributos não entram mais nessa conta. Eles ganham a própria regra no passo 6: "If the attribute-value is longer than 1024 octets, ignore the cookie-av string and return to Step 1 of this algorithm". A seção 6.1 do rascunho derrubou o item dos 4.096 em correspondência, guardando só as contagens por domínio e total, com a nota de que "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".
Então a página do MDN sobre document.cookie, que ainda conta ao leitor que a 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", e o guia de cookies do próprio MDN, que fala em "a maximum size per cookie (usually 4KB)", estão os dois corretos sobre especificações diferentes. Os navegadores implementam a terceira.

O que cada navegador aplica?
Chromium e Firefox pousaram nos números da RFC 6265bis, e os dois colocam esses números no código como constantes nomeadas.
| Motor | Nome mais valor | Por valor de atributo | Cookies por domínio | Total de cookies |
|---|---|---|---|---|
| Chromium (Chrome, Edge) | 4.096 bytes | 1.024 bytes | 180 | 3.300 |
| Gecko (Firefox) | 4.096 bytes | 1.024 bytes | 180 | 3.000 |
| WebKit (Safari) | Não publicado | Não publicado | Não publicado | Não publicado |
O Chromium declara os dois limites de bytes em net/cookies/parsed_cookie.h, cada um com seu próprio comentário:
// 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;O Firefox declara o limite de bytes em netwerk/cookie/CookieValidation.cpp como constexpr uint32_t kMaxBytesPerCookie = 4096; e o aplica em uma função cujo comentário ainda cita a especificação de duas revisões atrás:
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;O teto de atributo mora separado, em netwerk/cookie/CookieParser.cpp, como constexpr uint64_t ATTRIBUTE_MAX_LENGTH = 1024;.
O Safari é o buraco. A Apple não publica nenhum limite de bytes por cookie, e o texto da WebKit sobre política de armazenamento coloca os cookies fora do sistema de cota que descreve, afirmando que "cookies and HTTP cache are currently not subject to the policy below" e que "they are not bounded by quota". O Safari impõe outras restrições a cookies, incluindo o teto de sete dias para cookies escritos por script, mas um teto de tamanho documentado não está entre elas. Planeje pelos números do Chromium e do Gecko e você fica seguro em todo lugar.
O que acontece quando um cookie passa do limite?
O cookie é descartado inteiro. Ele nunca é truncado, e o servidor nunca fica sabendo. A RFC 2965 escreveu a regra em 1999 e ela não mudou: "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". A RFC 6265bis diz o mesmo em linguagem de parser, instruindo o agente de usuário a "abort this algorithm and ignore the set-cookie-string entirely".
Como a falha é silenciosa na camada HTTP, o único sinal está no console do navegador, e o Firefox é o motor que dá um sinal aproveitável. O arquivo de strings necko.properties carrega o texto exato:
Painel em tempo real
Rastreamento de metas
Rastreamento sem cookies
Cookie "%1$S" is invalid because its size is too big. Max size is %2$S B.Um atributo grande demais produz uma mensagem diferente e mais fácil de deixar passar, porque o cookie em si ainda é definido, só que sem aquele atributo:
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.Esse segundo caso é o bug mais desagradável. Um valor de Path ou Domain acima de 1.024 bytes não mata o cookie, muda o escopo dele, então o cookie existe mas para de ser enviado onde você esperava.
Quantos cookies um domínio pode guardar?
O Chromium permite 180 por domínio e remove 30 de cada vez. As constantes em net/cookies/cookie_monster.cc são kDomainMaxCookies = 180, kDomainPurgeCookies = 30, kMaxCookies = 3300 e kPurgeCookies = 300. O cabeçalho explica a política em uma frase: "When the number of cookies gets to k{Domain,}MaxCookies purge down to k{Domain,}MaxCookies - k{Domain,}PurgeCookies". Ele também detalha como domínios registráveis dividem o orçamento: "the maximum number of cookies allowed for google.com and all of its subdomains will be 150-180".
O Firefox chega aos mesmos dois números declarando-os direto. netwerk/cookie/CookieCommons.h define kMaxCookiesPerHost = 180, kCookieQuotaPerHost = 150 e kMaxNumberOfCookies = 3000. Os dois motores, portanto, admitem 180 cookies por domínio registrável e caem para 150 quando estouram, e diferem só no teto global, 3.300 no Chromium contra 3.000 no Firefox.
Cookies particionados ganham orçamento próprio por cima. O kPerPartitionDomainMaxCookies = 180 e o kPerPartitionDomainMaxCookieBytes = 10240 do Chromium limitam o que um site incorporado pode guardar em uma partição, e o teto de bytes é o que pega primeiro na maioria das incorporações. Essa interação está coberta em como funcionam os cookies particionados CHIPS.
Os dois motores fazem expurgo, o que significa que um cookie definido com sucesso pode sumir depois sem nenhum código seu rodar. A RFC 6265bis diz isso sem rodeio: agentes de usuário "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)".

Por que o cabeçalho de requisição Cookie esbarra em outro teto?
Cada cookie no escopo é concatenado em um único cabeçalho de requisição Cookie em toda requisição que casa, e quem define o limite disso é o servidor, não o navegador. A seção 4.2.1 da RFC 6265bis coloca o número na mesa: "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".
Dois cookies de 4.096 bytes são individualmente legais e juntos preenchem um cabeçalho de 8.192 bytes, antes da linha de requisição ou de qualquer outro cabeçalho. O que salva um pouco é que a viagem de volta carrega menos que a de ida: "Notice that the cookie attributes are not returned". O cabeçalho de requisição contém só pares de nome e valor, então Expires, Path, Domain e SameSite custam armazenamento, não banda.
A conta que vale fazer antes de colocar um cookie grande no ar é a do lado da requisição:
bytes do cabeçalho = soma, entre os cookies no escopo, de (tamanho do nome + 1 + tamanho do valor + 2)
Doze cookies com média de 600 bytes de nome mais valor colocam cerca de 7.200 bytes em cada requisição para aquele domínio, incluindo cada requisição de imagem e de script. Um site que chega nesse ponto costuma se dar melhor guardando uma chave opaca no cookie e o conteúdo no servidor, ou mudando para uma abordagem que não define cookie nenhum, como faz o rastreamento sem cookies. Se você ainda está decidindo quais cookies são seus, cookies próprios e de terceiros traça essa linha.
Perguntas frequentes
O limite de 4.096 bytes inclui os atributos do cookie?
Depende de qual especificação você lê, e os navegadores atuais seguem a mais nova. A RFC 6265 media 4096 "as the sum of the length of the cookie's name, value, and attributes". A RFC 6265bis conta só "the name string and the value string" e dá a cada valor de atributo um limite separado de 1024 octetos, que é o que Chromium e Firefox implementam.
O que acontece com um cookie grande demais?
O navegador o descarta por inteiro e o servidor não recebe erro. A RFC 2965 exigia que um cookie impossível de armazenar "MUST be discarded, not truncated", e a RFC 6265bis manda o parser "abort this algorithm and ignore the set-cookie-string entirely". O Firefox registra Cookie "name" is invalid because its size is too big no console; a resposta de rede parece bem-sucedida.
Quantos cookies um domínio pode definir?
180 no Chromium e no Firefox, caindo para 150 quando estoura. O kDomainMaxCookies do Chromium é 180 e o kDomainPurgeCookies é 30; o kMaxCookiesPerHost do Firefox é 180 e o kCookieQuotaPerHost é 150. Subdomínios dividem o orçamento do domínio registrável em vez de ganharem o próprio.
Painel em tempo real
Rastreamento de metas
Rastreamento sem cookies
O limite é medido em caracteres ou em bytes?
Em bytes. A RFC 6265bis especifica 4096 octetos, o Chromium tipa sua constante como size_t sobre a string serializada do cookie, e valores fora do ASCII são codificados em percent-encoding ou UTF-8 antes da checagem. Um valor de caracteres multibyte consome o tamanho codificado, não a contagem de caracteres.
O limite vale para o cabeçalho de requisição Cookie inteiro?
Não. A regra de 4.096 bytes vale por cookie, no momento do armazenamento. O cabeçalho Cookie combinado é limitado pelo servidor, e a RFC 6265bis observa que "many popular implementations have default limits of 8192 octets", marca que dois cookies de tamanho máximo atingem sozinhos.
O que guardar no lugar de um cookie grande?
Guarde um identificador opaco de algumas dezenas de bytes e mantenha o conteúdo no servidor, indexado por esse identificador. O cookie passa a custar o mesmo em cada requisição, não importa quanto estado ele aponte, e o estado em si deixa de ser legível ou editável por qualquer coisa rodando na página.
O Safari aplica um limite de tamanho de cookie como Chrome e Firefox?
O Safari, ou WebKit, não publica um limite em bytes documentado para cookies. O post da WebKit sobre sua política de armazenamento exclui explicitamente os cookies do sistema de cota e afirma que eles são "not bounded by quota". O Safari impõe outras regras aos cookies, como o teto de sete dias para cookies escritos por script, mas um limite de tamanho não está entre elas. Seguir os números do Chromium e do Gecko mantém você seguro em qualquer navegador.
Por que o Chromium permite mais cookies no total do que o Firefox?
O Chromium limita o total a 3300 (kMaxCookies), o Firefox a 3000 (kMaxNumberOfCookies). Os dois motores concordam nos números por domínio, 180 permitidos e 150 após a purga, então a diferença só aparece no teto global. A RFC 6265 pede no mínimo 3000 cookies no total e a 6265bis cita 3000 como exemplo, então os motores divergem.
Cookies particionados têm um limite de tamanho separado?
O Chromium soma um orçamento por partição para cookies CHIPS, além do limite normal por domínio. kPerPartitionDomainMaxCookies é 180, e kPerPartitionDomainMaxCookieBytes limita a partição a 10240 bytes, um teto que na maioria dos embeds é atingido antes da contagem de cookies. Isso é separado do limite de 4096 bytes por cookie, ele limita o que um site incorporado pode guardar somando todos os seus cookies em uma partição.
Um cookie sobrevive a um atributo grande demais?
Um nome mais valor grandes demais fazem o cookie ser descartado por completo, mas um atributo grande demais não. O Firefox registra uma mensagem dizendo que o atributo foi rejeitado por causa do tamanho, e o cookie ainda assim é definido, só sem esse atributo. Um valor de Path ou Domain acima de 1024 bytes muda o escopo do cookie em vez de apagá-lo, então ele continua existindo mas para de ser enviado onde você esperava.
Este artigo foi útil?
Diga-nos o que pensa!
Veja-nos mais no Google
Um clique marca a Flowsery como fonte preferida e nossos artigos passam a aparecer mais acima nas suas Principais notícias, no modo IA e nas visões gerais com IA.
Antes de ir...
Flowsery
Analytics orientado para receitas para o seu site
Rastreie cada visitante, fonte e conversão em tempo real. Simples, poderoso e sem cookies.
Painel em tempo real
Rastreamento de metas
Rastreamento sem cookies
Termos relacionados do glossário


Como um atributo ausente decide cookie de sessão vs cookie persistente
Comparamos cookie de sessão vs cookie persistente pela RFC 6265 e pelo MDN: Expires e Max-Age, session restore, o teto de 400 dias e o consentimento na UE.


Por que a taxa de rejeição do GA4 é só a taxa de engajamento invertida
Sua taxa de rejeição do GA4 é a parcela de sessões não engajadas. Como o Google a define, como ela difere do Universal Analytics e onde adicioná-la.


O que o relatório de página de destino do GA4 conta e onde ele fica em branco
Em Reports, o relatório de página de destino do GA4 lista a primeira página de cada sessão. Onde achar, métricas padrão, linhas (not set) e como ver a origem.


Como o rastreamento de pesquisa no site do GA4 registra o que os visitantes digitam
Configure a pesquisa no site do GA4 com a medição aprimorada, adicione seus parâmetros, ache a dimensão Search term e rastreie buscas sem URL.


Como definir propriedades de usuário do GA4 e usá-las em relatórios
Defina propriedades de usuário do GA4 com gtag ou Tag Manager, registre cada uma como dimensão personalizada de usuário e respeite o limite de 25.


Como vincular o Search Console ao GA4 e publicar os relatórios
Veja como vincular o Search Console ao GA4 no Admin, quais papéis você precisa, como publicar os dois relatórios na Library e o que os dados não cruzam.
Artigos relacionados


O que aconteceu com a descontinuação dos cookies de terceiros no Chrome
No Chrome, a descontinuação dos cookies de terceiros foi de um plano de 2020 a um recuo em 2025. Cada anúncio do Google, o que o Chrome faz hoje e o impacto.


O que o bfcache faz com a navegação de volta e a sua contagem de pageviews
O bfcache, ou back/forward cache, restaura a página da memória ao voltar ou avançar. Veja quais páginas se qualificam e por que o analytics erra a conta.


Por que o CNAME cloaking não esconde mais rastreadores do Safari ou do Brave
Rastreadores usavam o CNAME cloaking para se passar por um subdomínio seu. Veja o truque de DNS, o limite de 7 dias do Safari e como Brave e uBlock o revelam.

