Save Systems: A Browser-Game Survey

I want to talk about save systems for a moment because they are doing more work in browser games than most players realise. The browser context creates specific design constraints around saving that desktop and console games do not have. Different games respond to those constraints differently, and the choices reveal a lot about who the developer thinks the audience is.

For my bus-commute testing methodology (covered in another post on this site), save behaviour is one of the things I evaluate first. Without robust saving, a game does not work for the kind of play sessions I am most often in. With it, a game becomes part of my regular rotation. The choice matters in a specific way.

Save categories

Browser games tend to use one of four save approaches. Let me lay them out before getting into trade-offs.

First, no save. The game is intended for single-session play. High-score arcade games typically work this way. You play, you get a score, you start over. There is nothing to save because each session is independent. Best for short-format games.

Second, local-only save. The game saves to your browsers local storage. Progress persists across sessions on the same browser and device, but it does not follow you to another device. If you clear cookies, your save is gone. Lightweight and works without server infrastructure. Best for longer single-player games where the developer does not want to maintain a backend.

Third, account-based save. You log in with an email or social account, and your progress saves to the developers server. Follows you across devices. Robust against cookie clearing. Requires the developer to maintain a server and handle account management. Best for substantial games where retention matters.

Fourth, anonymous-server save. The game generates a unique ID for your session and saves to the server under that ID, without requiring an email or login. The ID is stored in your browser. Robust against cookie clearing if the developer also sends you the ID by other means. Less common but a smart middle ground.

Each category has trade-offs that affect different audiences differently.

What the bus commute reveals

When I am playing on the bus, the save system has to handle interruptions smoothly. My bus stop arrives. I have to get off. The game has to save my exact state without me thinking about it. When I open the game again the next day, I should resume exactly where I left off.

Games that save automatically on every meaningful state change pass this test. Games that save only at checkpoints fail it, because checkpoints are rarely positioned where my bus stops are. I have abandoned several otherwise-good games because the checkpoint design did not respect my play context.

The Crystal Caves Metroidvania on this site (five stars from me) saves automatically when you enter any new room. Six months of intermittent play across maybe forty bus rides, and I never lost progress. The save system is one of the reasons that game works in my context.

Lesser adventures in the catalogue often use checkpoint-only saves. I have started those games and never finished them, not because they are bad but because the save model does not survive a bus stop.

What the developer is signaling

The save system is a tell about the developers understanding of the audience. A high-score arcade game with no save is signaling that they expect short, complete sessions. A long adventure game with checkpoint-only saves is signaling that they expect long, focused sessions in front of a desktop. A long adventure game with auto-save on state change is signaling that they understand their audience plays in fragmented sessions on phones.

Signal is not always accurate. Some developers ship checkpoint-only save by default because that is what the engine they used does. They have not actually thought about who their players are. Their game would benefit from a different save model but they have not gotten there.

Some developers ship auto-save because they understand the audience but execute it badly. The save fires too often and slows the game down. Or the save state is incomplete and you lose some progress (like inventory state) but not other progress (like world position). Half-broken auto-save is sometimes worse than checkpoint-only save because it builds false confidence.

The bigger problem: cross-device sync

Most browser games do not handle cross-device save. You start a game on your laptop. You want to continue on your phone at lunch. The game does not know it is the same player on a different device. You have to start over.

This is a real limitation of the local-only save model. Without an account-based or anonymous-server save model, your progress is tied to a specific browser on a specific device.

Fix exists. Browsers support sync APIs that can move local-storage data between devices logged into the same browser account (Chrome account, Firefox account, etc). Some browser games use this. Most do not.

For me, this is a major reason I sometimes prefer the account-based save model even though I do not generally like creating accounts to play things. The cross-device sync is worth the friction for games I want to play across contexts.

The privacy angle

Account-based saves have an obvious privacy cost. The developer now has your email and your play history. Most casual browser-game developers are not abusing this data, but the data exists and the privacy trade-off is real.

Anonymous-server saves split the difference. You get cross-session persistence without giving up your identity. The developer gets a unique-user identifier without knowing who you are. This is the most player-respectful model and I wish more games used it.

Reason most games do not is operational. Account systems are well-supported by frameworks and have well-known UX patterns. Anonymous-server saves require some custom development and have UX edge cases (what happens if the user clears cookies and loses the ID? how do they recover? how do you prevent abuse? what do you do when the same player wants two parallel saves?). Most browser-game developers ship account-based saves because that is what their tooling makes easy.

What to look for as a player

When you start a browser game on this site or anywhere else, check what the save system does. Play for five minutes. Close the browser. Open the game again. Did you resume where you left off?

If yes, the developer has thought about save. Trust them with longer sessions.

If you have to restart, the save model is either no-save or broken. For high-score arcade games, no-save is correct. For longer-form games, broken save is a real problem and worth flagging in your own decision about whether to invest play time.

Games on this site that I most enthusiastically recommend for fragmented-session play all have robust save systems. The Crystal Caves Metroidvania. Mini Golf Pro (you can leave mid-round and come back). The Sudoku Master implementation (saves at every digit you enter). The Number 2048 game that auto-saves your high score every move. These are the games that survive the bus-commute test.

Games I cannot recommend for fragmented play are often otherwise-good games whose save model assumes desktop-style sessions. Knight Adventure and Hero Saga both have content I would love to engage with but lose me at the checkpoint structure. They are correctly rated for what they are, just not games I would play in my main testing context.

Save systems are doing more work in 2026 than they did in the desktop era. The fragmented-session audience expects auto-save, expects cross-device, expects no-friction resume, and expects to never see a progress-lost dialog. The games that meet those expectations succeed in browser. The ones that do not are limiting their own audience without realising it.