Implementing Data Storage (chrome.storage) in a Browser Extension

Problem: Data in the extension is lost or not synchronized

When developing a Chrome browser extension, one of the most common mistakes is data loss upon service worker restart or settings not syncing across user devices. Many beginner developers rely on localStorage, but it doesn't work in background scripts under Manifest V3 and doesn't notify of changes in other contexts. As a result, a user changes the theme on a laptop — the desktop still shows the old theme, and the translation cache disappears after 30 seconds of inactivity. In one of our projects — a translator extension with 10,000 active users — we faced cache loss on every service worker restart. The solution was straightforward: a combination of chrome.storage.sync for settings and chrome.storage.local for cache. We have implemented storage for over 50 extensions and have 5 years of experience in this field.

Problems we solve

Settings not syncing occurs when a user changes the theme on one device but the other still shows the old one. chrome.storage.sync automatically syncs data via the user's Google account; the limit is 100 KB, which is sufficient for configuration.

Cache loss on service worker restart is a typical Manifest V3 issue: the SW is unloaded after 30 seconds of inactivity. Storing cache in variables will lose it. chrome.storage.local or session solves the problem.

Lack of typing leads to errors when reading data, especially during schema migrations. We create typed TypeScript wrappers with default values, eliminating undefined behavior.

How we implement storage: a case study

For the translator extension with 10,000 users, we designed a storage system: settings (theme, language, auto-translate) in chrome.storage.sync, translation cache in chrome.storage.local with LRU eviction at 8 MB. Here's the typed wrapper for settings:

// storage/store.ts type Settings = { theme: 'light' | 'dark' | 'system'; targetLang: string; autoTranslate: boolean; ignoredDomains: string[]; }; const defaultSettings: Settings = { theme: 'system', targetLang: 'ru', autoTranslate: false, ignoredDomains: [], }; export const settingsStore = { async get(): Promise<Settings> { const result = await chrome.storage.sync.get('settings'); return { ...defaultSettings, ...(result.settings ?? {}) }; }, async set(partial: Partial<Settings>): Promise<void> { const current = await this.get(); await chrome.storage.sync.set({ settings: { ...current, ...partial } }); }, async reset(): Promise<void> { await chrome.storage.sync.set({ settings: defaultSettings }); }, onChange(callback: (newSettings: Settings) => void): void { chrome.storage.onChanged.addListener((changes, area) => { if (area === 'sync' && 'settings' in changes) { callback({ ...defaultSettings, ...changes.settings.newValue }); } }); } }; 

Thanks to this, the extension reliably saves user choices and reacts instantly to changes. The cache averages 3 MB, but we implemented LRU eviction: entries not accessed for over 30 days are removed.

Why chrome.storage is more reliable than localStorage and other methods

Note: chrome.storage is the only option for service workers and synchronization. According to Google's documentation, chrome.storage.sync automatically syncs data (developer.chrome.com).

Process of working on your extension

1. Analysis: Determine data types, volume (if >10 MB, need sync?), sync requirements, and offline needs.
2. Design: Choose storage combination (local, sync, session, IndexedDB), design typed wrappers, plan eviction strategy (LRU, TTL).
3. Implementation: Write TypeScript code with full unit test coverage (Jest), use Repository pattern and factories for different storage types.
4. Testing: Verify behavior on SW restart, limit exceeded, multiple tabs, concurrent writes.
5. Deployment: Publish to Chrome Web Store with full API documentation.

What's included in the work

• Full storage code with typing and wrappers (TypeScript).
• API and architecture documentation (README).
• Migration guide from localStorage (if needed).
• Team training for maintenance and modifications (1 hour consultation).
• Warranty: we support the code for 3 months after delivery (bug fixes).

Timelines and cost

Development timelines for storage: from 3 to 10 working days depending on complexity (single storage type vs. combination). Cost is calculated individually after requirements analysis. Contact us for a free consultation and preliminary estimate.

How to ensure synchronization between devices?

For settings and other small data, use chrome.storage.sync. The limit is 100 KB total, but enough for configuration. On each change, data is automatically distributed to all devices where the extension is installed. For larger data (e.g., bookmarks), use chrome.storage.local with your own sync server or cloud service.

How to subscribe to changes and avoid data races?

Use the onChanged event. Subscribe in all extension contexts to sync UI and background processes. Example:

chrome.storage.onChanged.addListener((changes, areaName) => { if (areaName !== 'sync') return; if ('theme' in changes) { const { newValue } = changes.theme; applyTheme(newValue); } }); 

This pattern prevents data races because changes are processed sequentially.

Additional recommendations

chrome.storage.sync can store up to 100 KB, with a single key not exceeding 8 KB. For larger volumes, use chrome.storage.local or IndexedDB. To clear all data, call clear(), but note that sync clears data on all devices. chrome.storage automatically serializes objects to JSON, so functions, undefined, and symbols are not allowed. For binary data, use IndexedDB or base64 conversion (mind limits). On extension updates, implement versioning and migrations — store schema version separately.

Reliable data storage is the foundation of any extension. Order storage development for your project. Contact us for a free consultation and preliminary estimate.