Größe, Ablauf, Zugriff und Recht bei Local Storage vs. Cookies

Was ist der Unterschied zwischen Local Storage und Cookies?

Der Kernunterschied bei Local Storage vs. Cookies liegt darin, wohin die Daten gehen: Der Browser hängt Cookies an HTTP-Requests an den Server an, während Local Storage im Browser bleibt, bis ein Skript ihn ausliest und irgendwohin sendet. Alles andere folgt daraus. Der WHATWG HTML Standard, der localStorage definiert, sagt, er sei für Daten gebaut worden, mit denen Cookies schlecht umgehen, "because they are transmitted with every request."

Eigenschaft	Cookies	Local Storage
Definiert in	RFC 6265, wird ersetzt durch draft-ietf-httpbis-rfc6265bis	WHATWG HTML Standard, Abschnitt 12
Größe	Mindestens 4096 Byte pro Cookie (Minimum laut RFC 6265)	5 MiB pro Origin (MDN)
Ablauf	Expires oder Max-Age, sonst Ende der Sitzung	Keiner; bleibt bis zur Löschung
An den Server gesendet	Ja, im Cookie-Header passender Requests	Nie, außer ein Skript sendet ihn
Für JavaScript lesbar	Ja über document.cookie, außer bei HttpOnly	Immer, für jedes Skript im Origin
Sicherheitsattribute	HttpOnly, Secure, SameSite, Domain, Path	Keine
Geltungsbereich	Domain und Pfad; keine Trennung nach Port	Origin: Schema, Host und Port
Safari ITP	Per document.cookie gesetzte Cookies auf 7 Tage begrenzt	Gelöscht nach 7 Tagen Safari-Nutzung ohne Interaktion
ePrivacy Artikel 5(3)	Erfasst	Erfasst

Wie viele Daten fassen ein Cookie und Local Storage?

Ein Cookie fasst etwa 4 KB und Local Storage etwa 5 MiB pro Origin, ein Unterschied von mehr als dem Tausendfachen. Die Zahl für Cookies stammt aus RFC 6265, Abschnitt 6.1, und legt eine Untergrenze fest, keine Obergrenze: User Agents "SHOULD provide" mindestens "4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes)", mindestens "50 cookies per domain" und mindestens "3000 cookies total".

Der Nachfolge-Entwurf ändert den Charakter dieser Zahl. In draft-ietf-httpbis-rfc6265bis-22, datiert auf Dezember 2025 und im IETF-Datatracker als aktiver Internet-Draft auf dem Weg zum Proposed Standard geführt, muss der Browser "ignore the cookie entirely", wenn "the sum of the lengths of cookie-name and cookie-value is more than 4096 octets", und jeder Attributwert ist auf 1024 Oktette begrenzt. Das zu unterstützende Minimum ist zu einem harten Maximum geworden. Die Geschichte dieser Zahl steht im Beitrag über das Größenlimit für Cookies.

Der HTML Standard legt keine Größe für Local Storage fest. Er sagt nur, setItem() "Throws a QuotaExceededError if the new value couldn't be set." Die praktische Zahl stammt von MDNs Seite zu Speicherkontingenten: "Browsers can store up to 5 MiB of local storage, and 5 MiB of session storage per origin", wobei Web Storage "limited to 10 MiB of data maximum on all browsers" ist.

Von der Untergrenze zur Obergrenze

RFC 6265, die aktuelle Regel

• Nutzer-Agents sollen laut Empfehlung mindestens 4096 Byte pro Cookie bereitstellen
• Mindestens 50 Cookies pro Domain
• Mindestens 3000 Cookies insgesamt
• Ein Minimum, das der Browser erreichen soll, keine Grenze, die er einhalten muss

rfc6265bis-22, der Entwurf von Dezember 2025

• Der Browser muss das Cookie ab 4096 Oktetten vollständig ignorieren
• Jeder Attributwert ist auf 1024 Oktette begrenzt
• Aus derselben Zahl wird eine harte Obergrenze

Wann laufen Cookies und Local Storage ab?

Ein Cookie läuft ab, wenn sein Expires-Datum oder sein Max-Age erreicht ist, oder am Ende der Sitzung, wenn es keines von beiden hat, während Local Storage überhaupt nicht abläuft. MDN sagt es direkt: "localStorage data has no expiration time", außer im privaten Modus, wo er "cleared when the last 'private' tab is closed" wird. sessionStorage ist das kurzlebige Gegenstück und wird geleert, wenn die Seitensitzung endet.

Cookies bekommen eine Obergrenze. Abschnitt 5.5 des rfc6265bis-Entwurfs sagt, ein Browser "MUST limit the maximum age of the cookie" und "the limit SHOULD NOT be greater than 400 days (34560000 seconds) in the future."

Der HTML Standard überlässt die Löschung von Local Storage dem Browser: "User agents may, possibly in a manner configured by the user, automatically delete stored data after a period of time." Apple hat von dieser Erlaubnis Gebrauch gemacht.

Was wird mit jedem HTTP-Request gesendet?

Cookies werden mit jedem passenden HTTP-Request gesendet, Local Storage schickt der Browser nie von sich aus. RFC 6265 rät Servern, Cookies klein zu halten, "to minimize network bandwidth due to the Cookie header being included in every request." Der Entwurf ergänzt, dass "many popular implementations have default limits of 8192 octets" für einen Header, und dass ein Überschreiten "could result in requests to the server failing."

"Passend" heißt, dass der Request zu den Regeln für Domain, Pfad, Secure und SameSite des Cookies passt. Ein Wert in Local Storage erreicht einen Server nur, wenn Ihr eigenes Skript ihn ausliest und in einen Request, eine URL oder einen Body schreibt.

Kann JavaScript Cookies und Local Storage lesen?

JavaScript kann jeden Wert in Local Storage innerhalb seines Origins lesen und jedes Cookie außer denen mit HttpOnly. Die Storage-Schnittstelle im HTML Standard bietet genau sechs Member: length, key(), getItem(), setItem(), removeItem() und clear(). Keiner davon verbirgt einen Wert vor Skripten, also kann jedes Skript auf der Seite, auch ein Tag eines Drittanbieters oder eingeschleuster Code, localStorage.getItem() aufrufen.

Cookies haben eine Möglichkeit zum Ausschluss. RFC 6265, Abschnitt 4.1.2.6, sagt, 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)." Die Ankündigung von ITP 2.1 durch WebKit vom 21. Februar 2019 nennt die praktische Regel: "Authentication cookies should be Secure and HttpOnly to protect them against man-in-the-middle attacks, cross-site scripting attacks, and speculative execution attacks." Local Storage kann diese Regel nicht erfüllen, und deshalb gehört ein Sitzungstoken in ein HttpOnly-Cookie und nicht in localStorage.

Was bewirken die Attribute HttpOnly, Secure und SameSite?

Die drei Attribute schränken ein, wer ein Cookie lesen kann und wann der Browser es sendet, und Local Storage hat für keines davon eine Entsprechung.

• HttpOnly verbirgt das Cookie vor Skripten, wie oben zitiert. Ein über document.cookie gesetztes Cookie kann dieses Attribut nicht tragen, nur der Set-Cookie-Header eines Servers erzeugt eines.
• Secure bedeutet laut RFC 6265, Abschnitt 4.1.2.5, "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 ist im rfc6265bis-Entwurf in Abschnitt 4.1.2.7 definiert. Mit Strict gilt: "the cookie will only be sent along with 'same-site' requests." Mit Lax wird es zusätzlich "with 'cross-site' top-level navigations" gesendet. Mit None geht es mit "same-site and cross-site requests" mit. MDN ergänzt, dass SameSite=None das Attribut Secure voraussetzt und dass "some browsers use Lax as the default value if SameSite is not specified."

Auch der Geltungsbereich unterscheidet sich. Local Storage gehört zu genau einem Origin, also Schema, Host und Port zusammen. Cookies sind lockerer: RFC 6265, Abschnitt 8.5, stellt fest, dass "cookies do not provide isolation by port", und das Attribut Domain teilt ein Cookie über Subdomains hinweg.

Wie behandelt Safari Local Storage und Cookies?

Safari löscht Local Storage und jede andere Form von per Skript beschreibbarem Speicher nach sieben Tagen Safari-Nutzung ohne Interaktion des Nutzers mit der Website. WebKit kündigte die Regel am 24. März 2020 in "Full Third-Party Cookie Blocking and More" an und merkte an, dass "APIs like LocalStorage have no expiry function at all." ITP löscht "all of a website's script-writable storage after seven days of Safari use without user interaction on the site." Die Liste umfasst IndexedDB, LocalStorage, Media Keys, SessionStorage sowie Service-Worker-Registrierungen und -Caches.

Die Uhr zählt Tage der Safari-Nutzung, keine Kalendertage, und Web-Apps, die zum Home-Bildschirm hinzugefügt wurden, haben einen eigenen Zähler. Per document.cookie gesetzte Cookies hatte ITP 2.1 bereits im Februar 2019 auf sieben Tage begrenzt. Vom Server gesetzte Cookies entgehen beiden Regeln: Der Abschnitt zur Verdrängung bei MDN stellt fest, dass "cookies set by server are exempt from this eviction." Die Auslösebedingungen und die 24-Stunden-Variante erklärt der Beitrag darüber, wie das 7-Tage-Cookie-Limit von Safari funktioniert.

Behandelt das EU-Recht Local Storage anders als Cookies?

Nein. Das EU-Recht behandelt Local Storage genau wie ein Cookie, weil Artikel 5(3) der ePrivacy-Richtlinie den Vorgang des Speicherns und Auslesens regelt, nicht die Technik. Die konsolidierte Fassung der Richtlinie 2002/58/EG lautet:

Die Mitgliedstaaten stellen sicher, dass die Speicherung von Informationen oder der Zugriff auf Informationen, die bereits im Endgerät eines Teilnehmers oder Nutzers gespeichert sind, nur gestattet ist, wenn der betreffende Teilnehmer oder Nutzer auf der Grundlage von klaren und umfassenden Informationen, die er gemäß der Richtlinie 95/46/EG u. a. über die Zwecke der Verarbeitung erhält, seine Einwilligung gegeben hat. Dies steht einer technischen Speicherung oder dem Zugang nicht entgegen, wenn der alleinige Zweck die Durchführung der Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz ist oder wenn dies unbedingt erforderlich ist, damit der Anbieter eines Dienstes der Informationsgesellschaft, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wurde, diesen Dienst zur Verfügung stellen kann.

Das Wort "Cookie" kommt darin nicht vor. Die Guidelines 2/2023 des EDPB zum technischen Anwendungsbereich von Artikel 5(3), Version 2.0, angenommen am 7. Oktober 2024, sagen in Randnummer 37, dass die Richtlinie kein "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" vorsieht. Randnummer 44 nennt "cookies, local storage, WebSQL" in einem Atemzug. Sie zieht auch die eine Linie, die beide in der Praxis trennt: Ein Browser, der diese Information ausschließlich innerhalb des Geräts nutzt, betreibt kein "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."

Ein Skript, das eine Kennung in localStorage schreibt und sie später an einen Server sendet, speichert und liest also Informationen und braucht eine Einwilligung, sofern keine Ausnahme greift. Eine Tracking-ID aus einem Cookie in Local Storage zu verschieben, ändert das Verhalten des Browsers und lässt die rechtliche Antwort unverändert. Deshalb muss auch ein Tool, das als Cookieless Tracking beschrieben wird, sagen, was es auf dem Gerät speichert. Die Ausnahmen funktionieren für beide gleich. Sie hängen am Zweck, nicht an der Technik: Eine Nutzung, die bei einem Cookie als "unbedingt erforderlich" gilt, gilt mit derselben Begründung auch in Local Storage, und eine Nutzung, die bei einem Cookie eine Einwilligung braucht, braucht sie auch in Local Storage.

Häufig gestellte Fragen

Ist Local Storage sicherer als Cookies?

Nein. Jedes Skript im Origin kann Local Storage lesen, und es gibt keine Entsprechung zu HttpOnly. WebKit empfiehlt aus diesem Grund, Authentifizierung in Secure- und HttpOnly-Cookies zu halten.

Braucht Local Storage ein Cookie-Banner?

Local Storage braucht dieselbe Einwilligung wie ein Cookie, wenn er nicht unbedingt erforderlich ist. Artikel 5(3) der ePrivacy-Richtlinie erfasst "die Speicherung von Informationen" auf dem Gerät, unabhängig von der Speicher-API.

Wie groß ist das Limit von Local Storage?

MDN nennt 5 MiB pro Origin, dazu 5 MiB Session Storage. Der HTML Standard legt keine Zahl fest; setItem() wirft QuotaExceededError, wenn ein Schreibvorgang scheitert.

Läuft Local Storage ab?

Nein. Local Storage hat kein Ablaufattribut, doch Browser löschen ihn trotzdem: Safaris ITP nach sieben Tagen Safari-Nutzung ohne Interaktion, und der private Modus, wenn der letzte private Tab geschlossen wird.

Kann der Server Local Storage lesen?

Nein. Der Browser sendet Local Storage nie in einem Request. Der Server sieht einen Wert nur, wenn ein Skript ihn ausliest und sendet, während Cookies automatisch in den Cookie-Header gelangen.

Unterscheidet sich sessionStorage von localStorage?

Ja. sessionStorage gehört zu einem Tab und wird geleert, wenn diese Seitensitzung endet, während localStorage über alle Tabs des Origins geteilt wird und bestehen bleibt. Beide fallen unter Safaris Sieben-Tage-Regel.

Kann ein Session-Token sicher im Local Storage liegen?

Ein Session-Token gehört in ein Cookie mit den Attributen Secure und HttpOnly, nicht in den Local Storage, denn jedes Skript im selben Origin kann localStorage.getItem() aufrufen und den Wert auslesen. WebKits Ankündigung zu ITP 2.1 macht denselben Punkt für Authentifizierungs-Cookies. Der Local Storage hat kein Attribut, das einen Wert vor Skripten verbirgt.

Wie lange darf ein Cookie nach dem neuesten Cookie-Entwurf gültig sein?

Der rfc6265bis-Entwurf begrenzt die Lebensdauer eines Cookies erstmals: Abschnitt 5.5 verlangt, dass der Browser das maximale Alter eines Cookies begrenzt, und empfiehlt, dass dieses Limit 400 Tage nicht überschreitet. Für Local Storage gibt es im HTML Standard keine solche Regel, er überlässt das Löschen gespeicherter Daten allein dem Browser.

Teilen sich Cookies und Local Storage Daten über Subdomains hinweg?

Ein Cookie lässt sich über das Domain-Attribut auf mehrere Subdomains ausdehnen, und RFC 6265 hält fest, dass Cookies keine Isolation nach Port bieten. Beim Local Storage gibt es diese Option nicht: Er gehört zu einem einzigen Origin aus Schema, Host und Port, sodass ein Skript auf einer Subdomain den Local Storage der übergeordneten Domain nicht lesen kann.

Was passiert mit einem Cookie, das das 4096-Byte-Limit des Entwurfs überschreitet?

Nach draft-ietf-httpbis-rfc6265bis-22 muss der Browser das Cookie vollständig ignorieren, sobald Name und Wert zusammen mehr als 4096 Oktette ergeben. Damit wird aus der alten RFC-6265-Untergrenze, die Nutzer-Agents laut Empfehlung mindestens bereitstellen sollten, eine harte Obergrenze. Der HTML Standard legt für Local Storage keine vergleichbare Grenze fest; setItem() wirft nur dann einen QuotaExceededError, wenn der neue Wert nicht gesetzt werden konnte.