Browser Extension Sync: Unite Devices Without Data Loss

Browser Extension Sync: Unite Devices Without Data Loss

Imagine: a user sets up filters, collects bookmarks, and adds notes on their work laptop. Then switches to home PC — and everything is gone. Without sync, the extension loses its purpose. We've solved this for 30+ projects, including a note-taking extension with 10,000 active users processing 50,000 write operations daily. Sync is not just copying data: it's handling conflicts, storage limits, and offline scenarios.

Why chrome.storage.sync often falls short

Built-in Chrome (and Firefox) storage is a good start, but hard limits quickly become a bottleneck. According to the Chrome Extensions Storage API documentation, limits are:

For extension settings (themes, toggles) this is enough. But once notes, bookmarks, or history appear, users hit the limit. We've seen projects trying to store 200 KB of notes by splitting them into 8 KB keys — leading to slowdowns and confusion. chrome.storage.sync cannot resolve conflicts: when two devices write simultaneously, the last write wins, and one device's data is lost.

How to resolve conflicts during offline editing

Note: When a user edits data on two devices offline and then goes online, a collision occurs. The basic Last-Write-Wins (LWW) strategy loses changes. A more reliable approach is versioned objects with timestamps:

async function mergeSettings(incoming) { const local = await chrome.storage.sync.get('settings'); const current = local.settings ?? { version: 0, data: defaultSettings }; if (incoming.version <= current.version) { return current; } await chrome.storage.sync.set({ settings: incoming }); return incoming; } 

For serious data (collaborative notes, shared lists), we use CRDT (Conflict-free Replicated Data Types) — they guarantee consistency without a central server. In one project, we implemented CRDT using the yjs library, enabling synchronization of 1 MB of data with zero loss at a change frequency of 100 operations per second.

Why a custom backend is more reliable than chrome.storage.sync

If data volume exceeds 100 KB or real-time sync is needed, a custom server is essential. A backend allows:

• unlimited storage (PostgreSQL, Redis);
• real-time updates via WebSocket/SSE;
• versioning each object and rolling back changes;
• user authentication via OAuth (Google, GitHub).

Case: an organizer extension with 10,000 MAU. Initially used chrome.storage.sync — after a month, users complained about lost notes and sluggishness. We migrated to a custom backend (Node.js + Redis + PostgreSQL). Sync scheme: CRDT + version vectors. Result: sync speed increased 10x (from 5 seconds to 0.5 s), data loss ceased. Full integration took 3 weeks.

Authorization via chrome.identity

To associate data with a user, we use built-in OAuth. Example for Chrome:

async function signInWithGoogle() { return new Promise((resolve, reject) => { chrome.identity.getAuthToken({ interactive: true }, async (token) => { if (chrome.runtime.lastError) { reject(chrome.runtime.lastError); return; } const response = await fetch('https://www.googleapis.com/oauth2/v2/userinfo', { headers: { Authorization: `Bearer ${token}` } }); const userInfo = await response.json(); const authResponse = await fetch(`${API_BASE}/auth/google`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ googleToken: token }) }); const { accessToken, expiresAt } = await authResponse.json(); await chrome.storage.local.set({ authToken: accessToken, tokenExpiry: expiresAt, userInfo }); resolve(userInfo); }); }); } 

For Firefox, use browser.identity.launchWebAuthFlow. Store the token in chrome.storage.local (safer than sync). Refresh 5 minutes before expiry.

Real-time sync via service worker

If the extension runs on multiple monitors or in a team, real-time is needed. We use SSE (Server-Sent Events) — lighter than WebSocket, works via ReadableStream in a service worker (EventSource unavailable).

async function startRealTimeSync() { const token = await getAuthToken(); if (!token || eventSource) return; const response = await fetch(`${API_BASE}/sync/stream`, { headers: { Authorization: `Bearer ${token}` } }); const reader = response.body.getReader(); const decoder = new TextDecoder(); while (true) { const { done, value } = await reader.read(); if (done) break; const text = decoder.decode(value); const lines = text.split('\n').filter(l => l.startsWith('data: ')); for (const line of lines) { try { const event = JSON.parse(line.slice(6)); applyRemoteChanges([event]); } catch {} } } } 

On the server, we use Redis Pub/Sub — channels per userId. When a change occurs, the event is published, the service worker receives it and updates the UI. Delay: 100–300 ms.

What's included in the work and typical timelines

We analyze your extension, data volume, and user base. We design the sync architecture: choose between sync and backend, determine the authentication type. We implement the client module (Chrome and Firefox), server part (REST + WebSocket), and configure deployment (Docker, Nginx, Cloudflare). We document the API and merge strategy. We train your team.

Typical timelines:

• Basic sync via chrome.storage.sync: from 2 days.
• Full-featured backend with OAuth and real-time: from 2 to 4 weeks.
• CRDT for complex data: from 3 weeks.

Contact us for a preliminary assessment of your project. Order turnkey sync implementation.

Common mistakes when implementing sync

• Ignoring offline scenarios: user changes data without internet, then everything gets overwritten online. Solution: use version vectors instead of LWW.
• Overfilling chrome.storage.sync: uncontrolled data growth leading to write errors. Monitor volume and transition to backend in time.
• Choosing the wrong merge strategy: one approach fits, another is selected — unpredictable results. Test with real scenarios.
• Lack of authentication: different users' data gets mixed. Always tie data to an account.

Avoiding these mistakes yields robust sync that works even during network loss. Our solutions reduce development load by 30–50% using ready-made modules.