Tamanho, validade, acesso e lei em local storage vs cookies

Qual é a diferença entre local storage e cookies?

A diferença central em local storage vs cookies é para onde os dados vão: o navegador anexa cookies às requisições HTTP enviadas ao servidor, enquanto o local storage fica dentro do navegador até que um script o leia e o envie para algum lugar. Todo o resto decorre disso. O WHATWG HTML Standard, que define o localStorage, diz que ele foi criado para dados que os cookies tratam mal, "because they are transmitted with every request."

Propriedade	Cookies	Local storage
Definido em	RFC 6265, em substituição pelo draft-ietf-httpbis-rfc6265bis	WHATWG HTML Standard, seção 12
Tamanho	Pelo menos 4096 bytes por cookie (mínimo da RFC 6265)	5 MiB por origem (MDN)
Expiração	Expires ou Max-Age, ou fim da sessão	Nenhuma; fica até ser apagado
Enviado ao servidor	Sim, no header Cookie das requisições correspondentes	Nunca, a menos que um script o envie
Legível por JavaScript	Sim, via document.cookie, a menos que seja HttpOnly	Sempre, por qualquer script da origem
Atributos de segurança	HttpOnly, Secure, SameSite, Domain, Path	Nenhum
Escopo	Domínio e caminho; sem isolamento por porta	Origem: esquema, host e porta
Safari ITP	Cookies definidos por document.cookie limitados a 7 dias	Apagado após 7 dias de uso do Safari sem interação
Artigo 5(3) da ePrivacy	Coberto	Coberto

Quantos dados cabem em um cookie e no local storage?

Um cookie guarda cerca de 4 KB e o local storage guarda cerca de 5 MiB por origem, uma diferença de mais de mil vezes. O número do cookie vem da RFC 6265, seção 6.1, que fixa um piso, não um teto: os user agents "SHOULD provide" pelo menos "4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes)", pelo menos "50 cookies per domain" e pelo menos "3000 cookies total".

O draft que vai substituí-la muda a natureza desse número. No draft-ietf-httpbis-rfc6265bis-22, de dezembro de 2025 e listado no datatracker da IETF como Internet-Draft ativo a caminho de Proposed Standard, o navegador deve "ignore the cookie entirely" se "the sum of the lengths of cookie-name and cookie-value is more than 4096 octets", e cada valor de atributo fica limitado a 1024 octetos. O mínimo a suportar virou um máximo rígido. A história desse número está no texto sobre o limite de tamanho de cookie.

O HTML Standard não fixa tamanho para o local storage. Ele só diz que setItem() "Throws a QuotaExceededError if the new value couldn't be set." O número de trabalho vem da página do MDN sobre cotas de armazenamento: "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin", com o Web Storage "limited to 10 MiB of data maximum on all browsers."

Do mínimo ao máximo

RFC 6265, a regra atual

• Os user agents deveriam oferecer pelo menos 4096 bytes por cookie, segundo a recomendação
• Pelo menos 50 cookies por domínio
• Pelo menos 3000 cookies no total
• Um mínimo que o navegador deveria alcançar, não um limite que precisava respeitar

rfc6265bis-22, o rascunho de dezembro de 2025

• O navegador precisa ignorar o cookie por completo acima de 4096 octetos
• Cada valor de atributo limitado a 1024 octetos
• O mesmo número virou um máximo obrigatório

Quando cookies e local storage expiram?

Um cookie expira quando a data de Expires ou o Max-Age se esgota, ou no fim da sessão se não tiver nenhum dos dois, enquanto o local storage não tem expiração nenhuma. O MDN diz isso diretamente: "localStorage data has no expiration time", exceto na navegação privada, em que ele é "cleared when the last 'private' tab is closed." O sessionStorage é o irmão de vida curta e é apagado quando a sessão da página termina.

Os cookies estão ganhando um limite superior. A seção 5.5 do draft rfc6265bis diz que um navegador "MUST limit the maximum age of the cookie" e que "the limit SHOULD NOT be greater than 400 days (34560000 seconds) in the future."

O HTML Standard deixa a exclusão do local storage a cargo do navegador: "User agents may, possibly in a manner configured by the user, automatically delete stored data after a period of time." A Apple usou essa permissão.

Qual deles é enviado em toda requisição HTTP?

Os cookies são enviados em toda requisição HTTP correspondente, e o local storage nunca é enviado pelo navegador por conta própria. A RFC 6265 recomenda aos servidores manter os cookies pequenos "to minimize network bandwidth due to the Cookie header being included in every request." O draft acrescenta que "many popular implementations have default limits of 8192 octets" para um header, e que ultrapassá-los "could result in requests to the server failing."

"Correspondente" significa que a requisição se encaixa nas regras de domínio, caminho, Secure e SameSite do cookie. Um valor no local storage só chega a um servidor se o seu próprio script o ler e o colocar em uma requisição, uma URL ou um corpo.

O JavaScript consegue ler cookies e local storage?

O JavaScript consegue ler todos os valores do local storage da sua origem e todos os cookies, menos os marcados como HttpOnly. A interface Storage do HTML Standard expõe exatamente seis membros: length, key(), getItem(), setItem(), removeItem() e clear(). Nenhum deles esconde um valor dos scripts, então qualquer script da página, incluindo uma tag de terceiros ou código injetado, pode chamar localStorage.getItem().

Os cookies têm uma forma de sair disso. A RFC 6265, seção 4.1.2.6, diz que o HttpOnly "instructs the user agent to omit the cookie when providing access to cookies via 'non-HTTP' APIs (such as a web browser API that exposes cookies to scripts)." O anúncio do ITP 2.1 do WebKit, de 21 de fevereiro de 2019, dá a regra prática: "Authentication cookies should be Secure and HttpOnly to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks." O local storage não tem como cumprir essa regra, e é por isso que um token de sessão pertence a um cookie HttpOnly, não ao localStorage.

O que fazem os atributos HttpOnly, Secure e SameSite?

Os três atributos restringem quem lê um cookie e quando o navegador o envia, e o local storage não tem equivalente para nenhum deles.

• HttpOnly esconde o cookie dos scripts, como citado acima. Um cookie definido via document.cookie não pode levá-lo, então só o header Set-Cookie de um servidor cria um.
• Secure, segundo a RFC 6265, seção 4.1.2.5, significa que "the user agent will include the cookie in an HTTP request only if the request is transmitted over a secure channel (typically HTTP over Transport Layer Security (TLS))."
• SameSite é definido no draft rfc6265bis, seção 4.1.2.7. Com Strict, "the cookie will only be sent along with 'same-site' requests." Com Lax, ele também vai "with 'cross-site' top-level navigations." Com None, ele vai com "same-site and cross-site requests." O MDN acrescenta que SameSite=None exige Secure e que "some browsers use Lax as the default value if SameSite is not specified."

O escopo também é diferente. O local storage pertence a uma única origem, ou seja, esquema, host e porta juntos. Os cookies são mais frouxos: a RFC 6265, seção 8.5, afirma que "cookies do not provide isolation by port", e o atributo Domain compartilha um cookie entre subdomínios.

Como o Safari trata local storage e cookies?

O Safari apaga o local storage e todas as outras formas de armazenamento gravável por script após sete dias de uso do Safari sem interação do usuário com o site. O WebKit anunciou a regra em 24 de março de 2020 no post "Full Third-Party Cookie Blocking and More", observando que "APIs like LocalStorage have no expiry function at all." O ITP apaga "all of a website's script-writable storage after seven days of Safari use without user interaction on the site." A lista cobre IndexedDB, LocalStorage, media keys, SessionStorage e registros e cache de service workers.

O relógio conta dias de uso do Safari, não dias corridos, e web apps adicionados à tela inicial têm contador próprio. Os cookies definidos por document.cookie já tinham sido limitados a sete dias pelo ITP 2.1 em fevereiro de 2019. Cookies definidos pelo servidor escapam das duas regras: a seção sobre remoção do MDN afirma que "cookies set by server are exempt from this eviction." As condições de disparo e a variante de 24 horas estão em como funciona o limite de 7 dias do Safari para cookies.

O direito da UE trata o local storage de forma diferente dos cookies?

Não. O direito da UE trata o local storage exatamente como um cookie, porque o artigo 5(3) da ePrivacy regula o ato de armazenar e ler, não a tecnologia. O texto consolidado da Diretiva 2002/58/CE, na versão oficial em português publicada no EUR-Lex, diz:

Os Estados-Membros asseguram que o armazenamento de informações ou a possibilidade de acesso a informações já armazenadas no equipamento terminal de um assinante ou utilizador só sejam permitidos se este tiver dado o seu consentimento prévio com base em informações claras e completas, nos termos da Directiva 95/46/CE, nomeadamente sobre os objectivos do processamento. Tal não impede o armazenamento técnico ou o acesso que tenha como única finalidade efectuar a transmissão de uma comunicação através de uma rede de comunicações electrónicas, ou que seja estritamente necessário ao fornecedor para fornecer um serviço da sociedade da informação que tenha sido expressamente solicitado pelo assinante ou pelo utilizador.

A palavra "cookie" não aparece. As Guidelines 2/2023 do EDPB sobre o alcance técnico do artigo 5(3), versão 2.0 adotada em 7 de outubro de 2024, dizem no parágrafo 37 que a diretiva não impõe "upper or lower limit on the length of time that information must persist on a storage medium to be counted as stored, nor is there an upper or lower limit on the amount of information to be stored." O parágrafo 44 cita "cookies, local storage, WebSQL" juntos. Ele também traça a única linha que os separa na prática: um navegador que usa essa informação estritamente dentro do dispositivo não está fazendo "gaining of access" "as long as the information does not leave the device, but when this information or any derivation of this information is accessed, Article 5(3) ePD would apply."

Então um script que grava um identificador no localStorage e depois o envia a um servidor armazena e acessa informações, e precisa de consentimento a menos que uma exceção se aplique. Mover um ID de rastreamento de um cookie para o local storage muda o comportamento do navegador e deixa a resposta jurídica igual, e é por isso que uma ferramenta descrita como rastreamento sem cookies ainda precisa dizer o que armazena no dispositivo. As exceções funcionam do mesmo jeito para os dois. Elas dependem da finalidade, não da tecnologia, então um uso que conta como "estritamente necessário" em um cookie conta pelo mesmo raciocínio no local storage, e um uso que precisa de consentimento em um cookie precisa dele no local storage também.

Perguntas frequentes

O local storage é mais seguro que os cookies?

Não. Qualquer script da origem consegue ler o local storage, e ele não tem equivalente ao HttpOnly. O WebKit recomenda manter a autenticação em cookies Secure e HttpOnly por esse motivo.

O local storage precisa de banner de cookies?

Precisa do mesmo consentimento que um cookie quando não é estritamente necessário. O artigo 5(3) da ePrivacy cobre "o armazenamento de informações" no dispositivo, qualquer que seja a API de armazenamento.

Qual é o limite de tamanho do local storage?

O MDN indica 5 MiB por origem, mais 5 MiB de session storage. O HTML Standard não fixa número; setItem() lança QuotaExceededError quando uma gravação falha.

O local storage expira?

Não. O local storage não tem atributo de expiração, embora os navegadores ainda o apaguem: o ITP do Safari após sete dias de uso do Safari sem interação, e a navegação privada quando a última aba privada é fechada.

O servidor consegue ler o local storage?

Não. O navegador nunca envia o local storage em uma requisição. O servidor só vê um valor se um script o ler e o enviar, enquanto os cookies entram no header Cookie automaticamente.

O sessionStorage é diferente do localStorage?

Sim. O sessionStorage pertence a uma aba e é apagado quando a sessão daquela página termina, enquanto o localStorage é compartilhado entre as abas da origem e persiste. Os dois caem na regra de sete dias do Safari.

Um token de sessão pode ficar seguro no local storage?

Um token de sessão pertence a um cookie marcado como Secure e HttpOnly, não ao local storage, porque qualquer script da origem pode chamar localStorage.getItem() e lê-lo. O anúncio do ITP 2.1 da WebKit faz a mesma observação sobre cookies de autenticação. O local storage não tem nenhum atributo que esconda um valor dos scripts.

Por quanto tempo um cookie pode durar segundo o rascunho mais recente?

O rascunho rfc6265bis limita pela primeira vez a duração de um cookie: a seção 5.5 exige que o navegador limite a idade máxima de um cookie e recomenda que esse limite não passe de 400 dias. O local storage não tem regra parecida no HTML Standard, que deixa a exclusão dos dados armazenados a critério do navegador.

Cookies e local storage compartilham dados entre subdomínios?

Um cookie pode ser compartilhado entre subdomínios pelo atributo Domain, e a RFC 6265 registra que cookies não oferecem isolamento por porta. O local storage não tem essa opção: pertence a uma única origem definida por esquema, host e porta juntos, então um script de um subdomínio não consegue ler o local storage do domínio principal.

O que acontece com um cookie que passa do limite de 4096 bytes do rascunho?

Segundo o draft-ietf-httpbis-rfc6265bis-22, o navegador precisa ignorar o cookie por completo assim que a soma do nome e do valor ultrapassa 4096 octetos. Isso transforma o antigo mínimo da RFC 6265, um piso que os user agents deviam oferecer como recomendação, em um teto obrigatório. O HTML Standard não fixa um limite parecido para o local storage; o setItem() só lança QuotaExceededError quando o novo valor não pôde ser gravado.