Cloud Saves for Browser Games: Syncing Progress Across Devices

2026-10-05 · 10 min read

The Problem With Local-Only Saves

Browser games store progress in localStorage by default. It works well enough on a single device, but it has real limits that bite you the moment players care about their progress. localStorage is device-bound — a player who builds a 200-hour farm on their laptop has zero access to it on their phone. It's volatile — clearing browser data wipes everything. And it's small — most browsers cap it at 5-10MB per origin.

If your game has any retention at all, players will eventually ask: "Can I play on my other device?" or worse, they'll lose their save and never come back. Cloud saves solve both problems, but building a sync system for a browser game introduces challenges you won't find in native game development.

localStorage Gotchas You Should Know

Before you build cloud sync, understand exactly how localStorage fails. These aren't edge cases — they're common enough that your players will hit them.

• Private browsing = no persistence. Safari's private mode used to throw on setItem() calls. Modern Safari allows writes but wipes them when the tab closes. Firefox and Chrome private mode behave similarly. If your game relies on localStorage as the only save mechanism, private-browsing players lose everything every session.
• Safari aggressive cleanup. Safari on iOS can purge localStorage data after 7 days of inactivity under storage pressure. Apple's Intelligent Tracking Prevention treats localStorage like cookies for sites the user hasn't interacted with recently. Your player's 50-hour save file can vanish because they took a week off.
• Size limits vary. Chrome and Firefox give you about 5MB. Safari gives you 5MB but measures it differently (UTF-16 encoding means your 5MB is effectively 2.5MB of ASCII text). Some mobile browsers give you even less. There's no reliable way to query the remaining quota — you just try to write and catch the exception.
• Synchronous API blocks the main thread. getItem() and setItem() are synchronous. On a large save (500KB+), the stringify-and-write operation can cause a visible frame stutter. This gets worse on low-end phones.

IndexedDB as a Better Local Store

IndexedDB solves most of localStorage's pain points. It's asynchronous, so reads and writes don't block the game loop. It supports structured data natively — you can store objects, arrays, and binary blobs without serializing to strings. And the storage limits are dramatically higher: most browsers allow hundreds of megabytes, sometimes gigabytes, per origin.

The trade-off is complexity. IndexedDB has a callback-heavy API that feels archaic compared to modern JavaScript. Wrap it in a Promise-based helper or use a library like idb (by Jake Archibald, under 2KB gzipped) that makes it feel like a normal async key-value store.

IndexedDB also survives Safari's 7-day purge if you request persistent storage via navigator.storage.persist(). Browser support is excellent — every modern browser has had IndexedDB since 2015. Use it as your primary local store, with localStorage as a fallback for settings and small metadata.

When You Need Cloud Sync

Not every browser game needs a backend. If your game is a quick 10-minute puzzle, localStorage is fine. But you need cloud sync when:

• Multi-device play. Players expect to pick up where they left off on any device. A farming sim with 100+ hour saves absolutely needs this.
• Long-term persistence. Games with deep progression systems can't afford to lose saves. Cloud storage is the only reliable long-term store — browser storage is fundamentally disposable.
• Anti-cheat. If your game has leaderboards, competitive elements, or in-app purchases, server-side save validation prevents players from editing localStorage to give themselves infinite gold.
• Cross-browser play. A player who switches from Chrome to Firefox on the same machine loses their localStorage data. Cloud saves make the browser irrelevant.

Server-Side Architecture

A cloud save backend can be surprisingly simple. At its core, you need three things: an identity, a storage endpoint, and versioned save slots.

Identity. For casual browser games, anonymous device IDs work well. Generate a UUID on first launch, store it in both localStorage and IndexedDB, and use it as the player's identity. If you want account linking later, let players attach an email to their anonymous ID. Don't force signup to save — that kills retention.

REST endpoint. Two routes cover the basics: PUT /saves/:slotId to upload a save and GET /saves/:slotId to download one. Authenticate requests with the device ID token in a header. Add a GET /saves list endpoint so the game can show available save slots on the load screen.

Versioned slots. Store each save with a monotonically increasing version number. When the client saves, it sends its current version number. The server increments the version on write and returns the new version. This lets you detect conflicts: if the client sends version 5 but the server is on version 6, someone else (or another device) wrote in between.

Conflict Resolution Strategies

Conflicts happen when a player plays offline on two devices and then both come online. You have three options:

• Last-write-wins. The most recent save overwrites the older one. Simple to implement, but the player loses progress from the overwritten device. Use timestamps and always pick the save with more playtime — not just the later wall-clock time (clocks can be wrong).
• Merge. Combine the two saves by taking the maximum of each field: highest money, most items, furthest quest progress. This works well for additive progression systems but fails when state can go backwards (spending money, using items). Complex to implement correctly.
• Player choice. Show both saves side by side with metadata (playtime, last location, key stats) and let the player pick. This is the safest option and what most AAA games do. It respects player agency and avoids silent data loss.

For most indie browser games, player choice with a last-write-wins fallback (if the player dismisses the dialog) is the best balance of simplicity and correctness.

Data Format and Versioning

Your cloud save format should be a superset of your local save format with additional metadata for sync. Include a schema version, a sync version (server-assigned), a client ID, and a checksum.

When you add new game features, bump the schema version and write a migration. The server should store saves as opaque blobs — it doesn't need to understand the save format. The client handles all migration logic on load.

Design your schema for backward compatibility from day one. New fields should have defaults so that an old save loaded without migration still produces a playable state. Never rename or remove fields in the same version — add a new field and deprecate the old one.

Compression and Bandwidth

Save data grows as players progress. A farming game save might start at 2KB and grow to 200KB after 100 hours. Uploading 200KB every 30 seconds burns mobile data and hits rate limits.

• Gzip the save data. JSON compresses extremely well — expect 70-85% reduction. Use CompressionStream (native browser API, no library needed) or pako for broader support. Send the compressed blob with Content-Encoding: gzip.
• Delta sync. Only send fields that changed since the last sync. Track dirty flags per subsystem (inventory changed, world changed, settings changed). The server applies the delta to the stored save. This cuts bandwidth by 90%+ for routine saves where only one or two values changed.
• Batch saves. Don't sync on every auto-save. Save locally every 30 seconds but sync to the cloud every 2-5 minutes, on tab close, and on manual save. Queue sync operations and deduplicate — if two local saves happen before a sync, only upload the latest.

Security Considerations

Never trust client data. A player can open DevTools and send any JSON to your save endpoint. Server-side validation is essential:

• Schema validation. Reject saves that don't match your expected structure. Check types, ranges, and required fields.
• Rate limiting. Cap save uploads to a reasonable frequency — 1 per 10 seconds is generous. Without rate limits, a malicious client can spam your storage backend.
• Size limits. Set a maximum save size (1MB is generous for most games). Reject anything larger.
• Plausibility checks. If a player has 999,999 gold after 2 minutes of playtime, flag or reject the save. You don't need perfect anti-cheat — basic sanity checks catch the most common edits.
• Don't store secrets in saves. Session tokens, API keys, and server-side state should never appear in save data that the client can read.

Offline-First Design

Cloud saves should enhance local saves, not replace them. Design your system offline-first:

• Always save locally. Every save writes to IndexedDB immediately, regardless of network state. The local save is the source of truth for the current device.
• Sync when online. Check navigator.onLine before attempting a sync. Listen for the online event to trigger a sync when connectivity returns. Don't block gameplay on sync — it happens in the background.
• Queue failed syncs. If a sync request fails (network error, server down, rate limited), queue it with exponential backoff. Store the queue in IndexedDB so it survives page reloads. Process the queue FIFO on reconnect.
• Show sync status. Give the player a small indicator: a cloud icon with a checkmark (synced), a spinning arrow (syncing), or a warning triangle (offline/failed). Don't make it intrusive — a subtle icon in the corner is enough. Players should know their save is safe without thinking about it.

The golden rule: if the internet goes down mid-session, the player should notice nothing. They keep playing, saves keep writing locally, and everything syncs when the connection comes back. Your game should never show a "connection required" error for save functionality.