What survives a reload: progress, favourites and public scores
Understand three different storage boundaries before resetting a game or changing devices.
Browser Games editorial · Updated November 2, 2026
Portal history is a convenience
Favourites and recently started games help you return to a page in the same browser. They are not a login, a backup or a record of every game action. A successful game start and a viewed cover are different events. Storage being blocked can make these conveniences temporary while allowing the game itself to continue.
Individual games own their saves
Games can store progress in localStorage or IndexedDB under separate namespaces. KEYLINE uses browser-local profile, settings and tour records; Junk Magnet preserves workshop and continuation behaviour. A portal history clear is not a reliable way to reset all such databases. Check the game’s reset or export controls and browser site-data tools.
Switching portal language should not be used to create a separate identity. Another device or browser profile can have an independent save even when the same public URL is opened. Before clearing data to fix a loading issue, use Retry and collect an error report so the diagnosis does not destroy useful progress.
Public submissions and consent are separate
A submitted leaderboard score is server-side. Deleting local history does not remove the published nickname and score. Ask support to handle a public record and provide only what is necessary to locate it. Do not include passwords or excessive personal documents.
Advertising consent and optional analytics choices also have their own controls. Deleting a favourite neither withdraws advertising consent nor removes third-party cookies. Use the available advertising privacy interface and analytics settings, and consult the Privacy page for provider links and request details. This separation helps you choose the smallest reset that actually solves your problem.