Schlüssel-Wert-Storage in Browsern: localStorage, sessionStorage, IndexedDB und OPFS im Vergleich

Wer im Browser Daten zwischenspeichern will, hat heute vier ernstzunehmende Optionen: localStorage, sessionStorage, IndexedDB und das relativ junge Origin Private File System (OPFS). Die vier sehen auf den ersten Blick wie Varianten desselben Themas aus, sind aber technisch ziemlich verschieden. Eine falsche Wahl rächt sich entweder mit eingefrorenen UIs oder mit Daten, die nach jedem Refresh wieder weg sind. Dieser Artikel sortiert die Optionen und nennt klare Kriterien für die Auswahl.

Die schnelle Übersicht

Bevor wir in die Details gehen, vier Profile als mentale Landkarte. localStorage und sessionStorage sind synchrone Schlüssel-Wert-Speicher, die nur Strings ablegen und auf 5 bis 10 Megabyte begrenzt sind — mit dem Unterschied, dass localStorage den Tab überlebt und sessionStorage nicht. IndexedDB ist eine vollwertige asynchrone Datenbank mit strukturierten Objekten, Indizes und Transaktionen und bietet typischerweise hunderte Megabyte bis Gigabyte Speicher. OPFS ist ein privates virtuelles Dateisystem pro Origin, das echte Dateien mit Random Access erlaubt und besonders dann seine Stärken ausspielt, wenn große Binärdaten oder eine SQLite-Datenbank im Browser landen sollen. Die spannende Frage ist nicht, welcher Speicher der beste ist — sondern für welche Aufgabe welcher Speicher passt.

localStorage: das Karteikästchen für Konfiguration

localStorage ist die einfachste und älteste Schlüssel-Wert-Schnittstelle im Browser. Sie speichert Strings unter String-Schlüsseln, lebt pro Origin, überlebt das Schließen des Tabs und ist synchron. Genau dieser letzte Punkt ist Stärke und Schwäche zugleich: Aufrufe wie localStorage.setItem('theme', 'dark') sind sofort wirksam, blockieren aber den Haupt-Thread, solange die Festplatte braucht. Bei kleinen Werten ist das egal — bei vielen oder großen Operationen wird daraus eine UI-Bremse. Wir haben mehrfach gesehen, wie Teams JSON-Blobs mit mehreren hundert Kilobyte in localStorage serialisieren und dann nicht verstehen, warum die Seite beim Tab-Wechsel kurz hakt. Für solche Mengen ist localStorage einfach nicht gedacht.

Klassische Einsatzfälle, in denen localStorage hervorragend passt: UI-Präferenzen wie Theme, Sprache oder Spaltenanordnung in einer Tabelle, Feature-Flags und A/B-Test-Bucket-Zuweisungen, kleine Tokens, die ohnehin schon im Browser landen würden (mit den üblichen XSS-Vorbehalten), Cache-Marker wie „ich habe diesen Hinweis schon geschlossen“. Was nicht hineingehört: alles, was strukturierter ist als ein Schlüssel-Wert-Paar, alles, was über ein paar Kilobyte hinausgeht, und alles, was schnell wieder weg sein sollte.

sessionStorage: derselbe Mechanismus, andere Lebenszeit

sessionStorage ist API-identisch zu localStorage, hat aber eine andere Persistenz-Regel: Die Daten leben nur, solange der Tab offen ist. Schließt der Nutzer den Tab, ist alles weg. Öffnet er die Seite in einem zweiten Tab, sieht er einen leeren Speicher — die Tabs teilen den Inhalt nicht. Das macht sessionStorage ungeeignet für Konfiguration, aber sehr nützlich für Zustand, der explizit nicht überleben soll: Mehr-Schritt-Formulare, Wizard-Fortschritte, kurzlebige Zwischenstände beim Bezahlvorgang. Wer hier localStorage verwendet, riskiert, dass alte Eingaben aus der letzten Session den Nutzer in einer neuen Sitzung verwirren.

IndexedDB: die richtige Datenbank im Browser

IndexedDB ist die Antwort auf alles, was nicht mehr in ein Schlüssel-Wert-Paar passt. Es ist eine vollwertige, transaktionale Datenbank im Browser, die strukturierte Objekte speichert, Indizes über Felder unterstützt und asynchron arbeitet. Statt localStorage.getItem öffnen Sie eine Datenbank, beginnen eine Transaktion, lesen aus einem Object-Store. Der Aufwand ist deutlich höher, aber dafür bekommen Sie Speichervolumen im Bereich hunderter Megabyte bis Gigabyte, strukturierte Objekte ohne JSON.stringify-Umwege, Indizes für Suche und sortierte Iteration, Transaktionen für konsistente Updates auf mehreren Stores sowie eine asynchrone API, die den Haupt-Thread nicht blockiert.

Der historische Ruf von IndexedDB war „mächtig, aber unangenehm“ — die rohe API ist tatsächlich umständlich, mit Events statt Promises und vielen kleinen Stolpersteinen. Heute löst praktisch jedes Projekt das mit einer dünnen Bibliothek wie idb oder Dexie, die die API auf moderne Promise-Patterns hebt. Damit ist IndexedDB für die meisten Anwendungen handhabbar geworden. Wir setzen es ein für Offline-fähige Anwendungen mit synchronisierten Datensätzen (zum Beispiel CRMs mit lokaler Kundenliste), für Browser-basierte Editoren, die ein Dokumentenmodell halten müssen, und für Caches, die schneller lokal aus IndexedDB als per Netzwerk gefüllt werden können.

OPFS: ein virtuelles Dateisystem pro Origin

Das Origin Private File System ist die jüngste der vier Optionen. Es ist Teil der File System Access API und gibt jeder Origin einen privaten Speicherbereich, in dem sie sich verhalten kann wie auf einem klassischen Dateisystem: Dateien öffnen, schreiben, seeken, schließen. Die Dateien sind für die Origin privat — weder andere Webseiten noch der Nutzer selbst können direkt in dem Bereich blättern.

OPFS spielt seine Stärken aus, wenn Sie große, binäre Daten persistent halten wollen (etwa eine SQLite-Datenbank, ein Video, eine kompilierte WASM-Datei), wenn Sie partiellen Zugriff brauchen — OPFS unterstützt Random Access auf einzelne Bytes, anders als IndexedDB mit seinen Blobs — oder wenn Sie einen Web Worker für hochfrequente Schreiboperationen einsetzen können. Genau diese letzte Eigenschaft ist der eigentliche Treiber: OPFS ist die Grundlage, auf der SQLite im Browser läuft. Die offizielle SQLite-WASM-Distribution verwendet OPFS als Backing-Store. Wer also „SQLite im Browser“ sagt, meint heute meist „OPFS unter SQLite“. Das hat eine spürbare praktische Wirkung: Komplexe lokale Anwendungen, die früher entweder LocalStorage-Hacks oder einen Server brauchten, laufen jetzt vollständig im Browser mit echter SQL-Datenbank.

Was OPFS nicht ist: ein universeller Datei-Picker. Der Browser exponiert OPFS nicht im normalen Dateisystem. Wer dem Nutzer Dateien direkt anbieten will, etwa zum Speichern auf seinem Schreibtisch, braucht weiterhin die normale File System Access API oder einen Download-Trigger.

Entscheidungsleitfaden in vier Fragen

Wenn Sie an einem Punkt sind, an dem Sie sich entscheiden müssen, helfen vier Fragen. Wie groß sind die Daten? Unter 100 KB und nur String — localStorage. Darüber — IndexedDB oder OPFS. Sollen die Daten den Tab überleben? Nein — sessionStorage. Ja — alle anderen. Ist die Struktur ein Schlüssel-Wert-Paar oder ein Objektgraph? Schlüssel-Wert — localStorage. Objektgraph — IndexedDB. Brauchen Sie Random Access auf große Binärdaten? Ja — OPFS. Nein — IndexedDB.

Ein häufiger Anti-Pattern: alles in localStorage, weil die API am angenehmsten ist. Das funktioniert, bis die App auf einem schwächeren Gerät zum ersten Mal merklich hängt — und dann ist die Refaktorierung deutlich aufwändiger, als es eine saubere Auswahl von Anfang an gewesen wäre.

Was uns in der Praxis aufgefallen ist

Aus den letzten zwölf Monaten Projekt-Arbeit drei Beobachtungen, die in keiner offiziellen Dokumentation so deutlich stehen. Erstens: Die Browser-Quoten für IndexedDB und OPFS sind nicht garantiert. Wer ernsthaft offline-fähige Anwendungen baut, ruft navigator.storage.persist() auf und zeigt dem Nutzer einen Berechtigungs-Prompt. Ohne diesen Schritt kann der Browser bei Speicherknappheit aufräumen, ohne zu fragen.

Zweitens: Safari implementiert die Quoten enger als Chrome oder Firefox. Eine Anwendung, die in Chrome mit 200 MB in IndexedDB problemlos läuft, kann in Safari nach wenigen Tagen Inaktivität ihre Daten verlieren. Wir testen IndexedDB-Anwendungen daher immer explizit in Safari und mit aktiviertem „Prevent Cross-Site Tracking“.

Drittens: OPFS hat im Web Worker eine andere API als im Main-Thread — nämlich die deutlich performantere FileSystemSyncAccessHandle. Wer hochfrequent schreibt, kommt um einen Web Worker nicht herum. SQLite im Browser läuft genau aus diesem Grund im Worker.

Quellen: MDN Web Docs (Web Storage API, IndexedDB API, File System Access API), WHATWG (File System Standard, OPFS), web.dev (The origin private file system), SQLite-Dokumentation (WebAssembly & JavaScript), WebKit-Blog (Storage Quotas in Safari).