Why Browser Games Lose Your Progress (and How to Keep It)
A browser game that opens at level 1 after a week of play has almost never lost the save to a bug. The save is usually still sitting where it was written, in a different browser, a different profile or a storage area that a setting quietly emptied. Finding out which one is mostly a matter of matching the symptom to the cause.
Where the save lives
Every game on SalutGames writes its progress into the browser's local storage for salutgames.net, each under its own name: gravibot.save.v2, trapcastle.save.v1, lsl-save-v2 for Last-Second Landing, and so on for all 13 games. The site keeps two small lists in the same place, the 12 most recently played games and the favourites marked with the heart button.
There is no account and no server copy. That makes saving instant and private, and it also means a save belongs to one browser on one device.
Symptom and cause
| What happened | The usual cause |
|---|---|
| Progress gone after closing the tab | A private or incognito window |
| Gone every day on a school Chromebook | The device wipes data at sign-out |
| Gone after a few weeks away, on an iPhone or Mac | Safari's seven-day rule |
| Missing on the laptop but fine on the phone | Saves don't travel between devices |
| Different progress from the home screen icon | A separate storage area on iOS |
| Gone right after clearing browsing data | "Cookies and site data" was ticked |
| Gone on a phone that was almost full | The browser freed space |
Private windows. Private browsing is designed to forget. MDN's documentation on storage notes that data stored in a private window is usually deleted when the private session ends. A game played there works normally and starts over next time.
Managed Chromebooks. Schools and workplaces can turn on a ChromeOS setting called ephemeral mode, which wipes local user data when the user signs out. No website can work around it. If progress disappears every single day on a school device and nowhere else, this is almost certainly the reason.
Safari's seven-day rule. Since March 2020, Safari deletes all of a website's script-writable storage, local storage included, after seven days of Safari use without any interaction with that site. The count is days of using Safari, not calendar days. Every SalutGames game lives on the same site, so interacting with any of them counts as interacting with salutgames.net.
The home screen icon on iOS. A site added to the iPhone home screen runs as a separate web app with its own storage. WebKit's own description says these apps keep their own counter of days of use, and that their data is not expected to be deleted the same way. The Safari save and the home screen save simply never meet.
Clearing data. Clearing history or the cache leaves saves alone. Clearing "cookies and site data", or "website data" on an iPhone, deletes them with everything else.
A full device. Browsers store site data on a "best effort" basis by default. When a device runs low on space, they delete data from the least recently used sites first, one site at a time, until there is room again. A site can ask for persistent storage that is exempt from this, and Chrome and Safari decide whether to grant it from the person's history of interaction with the site.
Keeping a save safe
The habits that protect a save follow directly from the list above:
- Play in one browser, on one device, and in a normal window.
- When clearing data, clear history and cache rather than all site data.
- On an iPhone, pick either Safari or the home screen icon for a game, not both.
- On Safari, any visit with a tap keeps the seven-day count from running out.
None of the games has a save button. Each one writes its save by itself as progress is made, so closing the tab at the end of a break costs nothing.
Sources
- John Wilander, Full Third-Party Cookie Blocking and More, WebKit, 24 March 2020
- MDN, Storage quotas and eviction criteria
- Google, Ephemeral mode, Chrome Enterprise and Education Help
