Taille, expiration, accès et droit : local storage vs cookies

Quelle est la différence entre le local storage et les cookies ?

Dans le match local storage vs cookies, la différence centrale tient à la destination des données : le navigateur joint les cookies aux requêtes HTTP envoyées au serveur, alors que le local storage reste dans le navigateur jusqu'à ce qu'un script le lise et l'envoie ailleurs. Tout le reste en découle. Le WHATWG HTML Standard, qui définit localStorage, précise qu'il a été conçu pour des données que les cookies gèrent mal, "because they are transmitted with every request."

Propriété	Cookies	Local storage
Défini dans	RFC 6265, en cours de remplacement par draft-ietf-httpbis-rfc6265bis	WHATWG HTML Standard, section 12
Taille	Au moins 4096 octets par cookie (minimum de la RFC 6265)	5 Mio par origine (MDN)
Expiration	Expires ou Max-Age, ou fin de session	Aucune ; reste jusqu'à suppression
Envoyé au serveur	Oui, dans l'en-tête Cookie des requêtes correspondantes	Jamais, sauf si un script l'envoie
Lisible par JavaScript	Oui via document.cookie, sauf si HttpOnly	Toujours, par n'importe quel script de l'origine
Attributs de sécurité	HttpOnly, Secure, SameSite, Domain, Path	Aucun
Portée	Domaine et chemin ; aucune isolation par port	Origine : schéma, hôte et port
ITP de Safari	Cookies posés par document.cookie plafonnés à 7 jours	Supprimé après 7 jours d'utilisation de Safari sans interaction
Article 5(3) de la directive ePrivacy	Couvert	Couvert

Quelle quantité de données un cookie et le local storage peuvent-ils contenir ?

Un cookie contient environ 4 Ko et le local storage environ 5 Mio par origine, soit un écart de plus de mille fois. Le chiffre du cookie vient de la RFC 6265, section 6.1, qui fixe un plancher, pas un plafond : les user agents "SHOULD provide" au moins "4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes)", au moins "50 cookies per domain" et au moins "3000 cookies total".

Le brouillon de remplacement change la nature de ce chiffre. Dans draft-ietf-httpbis-rfc6265bis-22, daté de décembre 2025 et répertorié par le datatracker de l'IETF comme Internet-Draft actif en route vers le statut de Proposed Standard, le navigateur doit "ignore the cookie entirely" si "the sum of the lengths of cookie-name and cookie-value is more than 4096 octets", et chaque valeur d'attribut est limitée à 1024 octets. Le minimum à prendre en charge est devenu un maximum strict. L'histoire de ce chiffre est retracée dans l'article sur la limite de taille des cookies.

Le HTML Standard ne fixe aucune taille pour le local storage. Il dit seulement que setItem() "Throws a QuotaExceededError if the new value couldn't be set." Le chiffre de travail vient de la page de MDN sur les quotas de stockage : "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin", le Web Storage étant "limited to 10 MiB of data maximum on all browsers."

Du plancher au plafond

RFC 6265, la règle actuelle

• Les user agents devraient fournir au moins 4096 octets par cookie, selon la recommandation
• Au moins 50 cookies par domaine
• Au moins 3000 cookies au total
• Un minimum que le navigateur devait atteindre, pas une limite qu'il devait respecter

rfc6265bis-22, le brouillon de décembre 2025

• Le navigateur doit ignorer entièrement le cookie au-delà de 4096 octets
• Chaque valeur d'attribut plafonnée à 1024 octets
• Le même chiffre devient un maximum obligatoire

Quand les cookies et le local storage expirent-ils ?

Un cookie expire quand sa date Expires ou son Max-Age arrive à échéance, ou à la fin de la session s'il n'a ni l'un ni l'autre, alors que le local storage n'expire jamais. MDN le dit sans détour : "localStorage data has no expiration time", sauf en navigation privée, où il est "cleared when the last 'private' tab is closed." sessionStorage est son équivalent de courte durée et il est vidé à la fin de la session de page.

Les cookies se voient imposer une limite haute. La section 5.5 du brouillon rfc6265bis dit qu'un navigateur "MUST limit the maximum age of the cookie" et que "the limit SHOULD NOT be greater than 400 days (34560000 seconds) in the future."

Le HTML Standard laisse la suppression du local storage à l'appréciation du navigateur : "User agents may, possibly in a manner configured by the user, automatically delete stored data after a period of time." Apple a usé de cette permission.

Lequel est envoyé avec chaque requête HTTP ?

Les cookies sont envoyés avec chaque requête HTTP correspondante, et le navigateur n'envoie jamais le local storage de lui-même. La RFC 6265 invite les serveurs à garder les cookies petits "to minimize network bandwidth due to the Cookie header being included in every request." Le brouillon ajoute que "many popular implementations have default limits of 8192 octets" pour un en-tête, et que les dépasser "could result in requests to the server failing."

"Correspondante" signifie que la requête respecte les règles de domaine, de chemin, Secure et SameSite du cookie. Une valeur du local storage n'atteint un serveur que si votre propre script la lit et la place dans une requête, une URL ou un corps.

JavaScript peut-il lire les cookies et le local storage ?

JavaScript peut lire toutes les valeurs du local storage de son origine, et tous les cookies sauf ceux marqués HttpOnly. L'interface Storage du HTML Standard expose exactement six membres : length, key(), getItem(), setItem(), removeItem() et clear(). Aucun ne masque une valeur aux scripts, donc n'importe quel script de la page, y compris un tag tiers ou du code injecté, peut appeler localStorage.getItem().

Les cookies disposent d'une échappatoire. La RFC 6265, section 4.1.2.6, dit que 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)." L'annonce d'ITP 2.1 par WebKit, le 21 février 2019, en tire la règle pratique : "Authentication cookies should be Secure and HttpOnly to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks." Le local storage n'a aucun moyen de respecter cette règle, et c'est pourquoi un jeton de session a sa place dans un cookie HttpOnly et pas dans localStorage.

Que font les attributs HttpOnly, Secure et SameSite ?

Ces trois attributs limitent qui peut lire un cookie et quand le navigateur l'envoie, et le local storage n'a d'équivalent pour aucun d'eux.

• HttpOnly masque le cookie aux scripts, comme cité plus haut. Un cookie posé via document.cookie ne peut pas le porter, donc seul l'en-tête Set-Cookie d'un serveur en crée un.
• Secure, selon la RFC 6265, section 4.1.2.5, signifie 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 est défini dans le brouillon rfc6265bis, section 4.1.2.7. Avec Strict, "the cookie will only be sent along with 'same-site' requests." Avec Lax, il est aussi envoyé "with 'cross-site' top-level navigations." Avec None, il part avec les "same-site and cross-site requests." MDN ajoute que SameSite=None exige Secure, et que "some browsers use Lax as the default value if SameSite is not specified."

La portée diffère aussi. Le local storage appartient à une seule origine, c'est-à-dire au schéma, à l'hôte et au port réunis. Les cookies sont plus lâches : la RFC 6265, section 8.5, indique que "cookies do not provide isolation by port", et l'attribut Domain partage un cookie entre sous-domaines.

Comment Safari traite-t-il le local storage et les cookies ?

Safari supprime le local storage et toutes les autres formes de stockage accessible en écriture par script après sept jours d'utilisation de Safari sans interaction de l'utilisateur avec le site. WebKit a annoncé la règle le 24 mars 2020 dans "Full Third-Party Cookie Blocking and More", en notant que "APIs like LocalStorage have no expiry function at all." ITP supprime "all of a website's script-writable storage after seven days of Safari use without user interaction on the site." La liste couvre IndexedDB, LocalStorage, les media keys, SessionStorage, ainsi que les enregistrements et le cache des service workers.

Le compteur mesure des jours d'utilisation de Safari, pas des jours calendaires, et les web apps ajoutées à l'écran d'accueil ont leur propre compteur. Les cookies posés par document.cookie étaient déjà plafonnés à sept jours par ITP 2.1 depuis février 2019. Les cookies posés par le serveur échappent aux deux règles : la section sur l'éviction de MDN indique que "cookies set by server are exempt from this eviction." Les conditions de déclenchement et la variante de 24 heures sont détaillées dans le fonctionnement de la limite de 7 jours des cookies Safari.

Le droit de l'UE traite-t-il le local storage différemment des cookies ?

Non. Le droit de l'UE traite le local storage exactement comme un cookie, parce que l'article 5(3) de la directive ePrivacy régit l'acte de stocker et de lire, pas la technologie. La version consolidée de la directive 2002/58/CE se lit ainsi :

Les États membres garantissent que le stockage d'informations, ou l'obtention de l'accès à des informations déjà stockées, dans l'équipement terminal d'un abonné ou d'un utilisateur n'est permis qu'à condition que l'abonné ou l'utilisateur ait donné son accord, après avoir reçu, dans le respect de la directive 95/46/CE, une information claire et complète, entre autres sur les finalités du traitement. Cette disposition ne fait pas obstacle à un stockage ou à un accès techniques visant exclusivement à effectuer la transmission d'une communication par la voie d'un réseau de communications électroniques, ou strictement nécessaires au fournisseur pour la fourniture d'un service de la société de l'information expressément demandé par l'abonné ou l'utilisateur.

Le mot "cookie" n'y apparaît pas. Les Guidelines 2/2023 on the technical scope of Article 5(3) de l'EDPB, version 2.0 adoptée le 7 octobre 2024, disent au paragraphe 37 que la directive ne pose aucune "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." Le paragraphe 44 cite ensemble "cookies, local storage, WebSQL". Il trace aussi la seule ligne qui les sépare en pratique : un navigateur qui utilise ces informations strictement à l'intérieur de l'appareil ne constitue pas un "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."

Un script qui écrit un identifiant dans localStorage puis l'envoie plus tard à un serveur stocke donc des informations et y accède, et il lui faut un consentement sauf exemption applicable. Déplacer un identifiant de suivi d'un cookie vers le local storage change le comportement du navigateur et laisse la réponse juridique inchangée, ce qui explique pourquoi un outil présenté comme du suivi sans cookies doit quand même dire ce qu'il stocke sur l'appareil. Les exemptions fonctionnent de la même manière pour les deux. Elles dépendent de la finalité, pas de la technologie, donc un usage "strictement nécessaire" dans un cookie l'est pour les mêmes raisons dans le local storage, et un usage qui exige un consentement dans un cookie l'exige aussi dans le local storage.

Questions fréquentes

Le local storage est-il plus sûr que les cookies ?

Non. N'importe quel script de l'origine peut lire le local storage, et il n'a aucun équivalent de HttpOnly. WebKit recommande pour cette raison de garder l'authentification dans des cookies Secure et HttpOnly.

Le local storage nécessite-t-il une bannière de cookies ?

Il exige le même consentement qu'un cookie lorsqu'il n'est pas strictement nécessaire. L'article 5(3) de la directive ePrivacy couvre "le stockage d'informations" sur l'appareil, quelle que soit l'API de stockage.

Quelle est la limite de taille du local storage ?

MDN indique 5 Mio par origine, plus 5 Mio de session storage. Le HTML Standard ne fixe aucun chiffre ; setItem() lève QuotaExceededError quand une écriture échoue.

Le local storage expire-t-il ?

Non. Le local storage n'a pas d'attribut d'expiration, mais les navigateurs le suppriment quand même : l'ITP de Safari après sept jours d'utilisation de Safari sans interaction, et la navigation privée à la fermeture du dernier onglet privé.

Le serveur peut-il lire le local storage ?

Non. Le navigateur n'envoie jamais le local storage dans une requête. Le serveur ne voit une valeur que si un script la lit et l'envoie, alors que les cookies partent automatiquement dans l'en-tête Cookie.

sessionStorage est-il différent de localStorage ?

Oui. sessionStorage appartient à un seul onglet et il est vidé à la fin de la session de page, alors que localStorage est partagé entre les onglets de l'origine et persiste. Les deux tombent sous la règle des sept jours de Safari.

Un jeton de session peut-il rester en sécurité dans le local storage ?

Un jeton de session a sa place dans un cookie marqué Secure et HttpOnly, pas dans le local storage, car n'importe quel script de l'origine peut appeler localStorage.getItem() et le lire. L'annonce d'ITP 2.1 par WebKit fait la même remarque pour les cookies d'authentification. Le local storage ne possède aucun attribut capable de cacher une valeur aux scripts.

Combien de temps un cookie peut-il durer selon le dernier brouillon ?

Le brouillon rfc6265bis limite pour la première fois la durée de vie d'un cookie : la section 5.5 exige que le navigateur limite l'âge maximal d'un cookie et recommande de ne pas dépasser 400 jours. Le local storage ne connaît aucune règle de ce type dans le HTML Standard, qui laisse la suppression des données stockées à la seule discrétion du navigateur.

Les cookies et le local storage partagent-ils des données entre sous-domaines ?

Un cookie peut être partagé entre sous-domaines grâce à l'attribut Domain, et la RFC 6265 précise que les cookies n'offrent aucune isolation par port. Le local storage n'a pas cette option : il appartient à une seule origine, définie par le schéma, l'hôte et le port réunis, donc un script d'un sous-domaine ne peut pas lire le local storage du domaine parent.

Que devient un cookie qui dépasse la limite de 4096 octets du brouillon ?

Selon draft-ietf-httpbis-rfc6265bis-22, le navigateur doit ignorer entièrement le cookie dès que la somme de son nom et de sa valeur dépasse 4096 octets. Le minimum de l'ancienne RFC 6265, un plancher que les user agents devaient fournir par recommandation, devient ainsi un plafond obligatoire. Le HTML Standard ne fixe aucune limite comparable pour le local storage : setItem() ne lève une QuotaExceededError que lorsque la nouvelle valeur n'a pas pu être enregistrée.