Do HTML5 Games Work Offline? How Browser Caching Works

Search for "HTML5 games offline" and the answers split between yes and no because both are true in different situations. A browser game is a set of files, and it works offline exactly when the browser already has all of them and chooses to use them. Two mechanisms decide that: the HTTP cache every browser keeps automatically, and the service worker a site can add on purpose. Most casual game sites rely on the first and never build the second.

This article explains both mechanisms in plain terms, why the first is unreliable by design, what the second guarantees and costs, and where your progress lives while any of this happens. It ends with the facts about this site, which has no service worker and says so rather than promising offline play it does not control.

The HTTP cache: what the browser keeps without being asked#

Every browser keeps copies of files it has fetched, so that the next request for the same address can be answered from disk. Mozilla's documentation defines it simply: the HTTP cache stores a response associated with a request and reuses the stored response for subsequent requests. For a game that is one HTML file, a cached copy means the game can load without the network. For a game that pulls a hundred image files, every one of them has to be cached.

Whether a stored copy is used depends on headers the server attached when it sent the file. A max-age value says how long the copy counts as fresh; past that it is stale, and a stale copy is not thrown away but revalidated, meaning the browser asks the server whether it changed. Offline, that question cannot be asked, and browsers differ in whether they will show a stale copy anyway. That is the first reason offline play through the cache alone is unpredictable.

The second reason is eviction. The cache has a size budget, and the browser clears entries when it needs room, when the user clears browsing data, and sometimes on its own schedule. Nothing a site does can prevent that. A game that worked offline on the train yesterday may have been evicted overnight, and the player sees only that the page will not load.

Service workers: offline on purpose#

A site that wants to promise offline play uses a service worker, a script the browser runs in the background for that site. Mozilla's page on the Service Worker API describes them as proxy servers sitting between web applications, the browser and the network, intended among other things to enable effective offline experiences. The worker intercepts the page's requests and can answer them from a store it controls, which the browser does not evict casually.

The design patterns are well documented. Jake Archibald's offline cookbook on web.dev, which remains the standard reference, explains that with Service Workers, we gave developers a way to solve network connection. You get control over caching and how requests are handled, and catalogues the strategies: cache falling back to network for offline-first content, network falling back to cache for things that should be fresh, and stale-while-revalidate for a fast answer followed by a quiet update.

Service workers have conditions. They run only on HTTPS sites, with localhost as the development exception. The site has to write and register one, decide what to store and when to update it, and handle the case where the stored version and the live version differ. That is real engineering, which is why large web apps have service workers and most casual game portals do not. A game with a service worker will typically say so, often by offering to be installed as an app.

Where your progress lives, and why it does not need a connection#

Whether the game can load and whether it remembers you are separate questions, and the second has the friendlier answer. Most browser games save progress with the Web Storage API, usually localStorage, which Mozilla describes as storage for the document's origin whose data is saved across browser sessions, unlike sessionStorage, which is cleared when the page closes. Reading and writing it is a local operation; no connection is involved.

That storage is tied to the site's address, including the protocol, and lives on one device in one browser. It does not sync to another phone, it is not backed up by the site, and clearing the browser's site data erases it. Arrow Escape stores its highest level reached, the level to resume, and the best streak this way, under a single key, and has no account system that would move that record anywhere else.

So the realistic offline scenario has two parts. If the game's files are present and usable, it will load and will find your progress exactly where you left it. If the files are not present, the game will not load, and your progress is still there, waiting for the next time it does. The connection affects the first step only.

Mechanism	Who controls it	Offline guarantee	Used by this site
HTTP cache	The browser, guided by server headers	None; files may be stale or evicted	Yes, as every site is
Service worker	The site, deliberately	Yes, for whatever the worker stores	No
localStorage	The site, per origin and device	Progress is local; no network needed	Yes

What this site actually does, and does not promise#

The games here are single HTML files, about 50 kilobytes for Arrow Escape, that make no network requests of their own once loaded. That makes the offline case unusually simple: one cached file is the whole game. The surrounding site is a static build served from a content delivery network, and it sets caching headers for its images and its versioned script files so browsers can hold them. There is no service worker anywhere on the site.

The consequence is stated rather than hidden. If the browser holds a fresh cached copy of a game page and its file, the game may load without a connection. If the copy is stale, evicted or absent, it will not, and the site cannot change that outcome from its side. Offline play is a possibility here, not a feature, and a player who needs a guaranteed offline game should look for a site that has built one.

What the site does control is everything after the load. The performance article explains why the game runs entirely on the device once it has arrived, with no server round-trips per move, which is also why a flaky connection does not interrupt a level in progress. Progress writes to local storage after each level, so a dropped connection mid-session costs nothing.

Practical answers for the common situations#

The situations players actually meet are few, and each has a clear answer under the mechanics above:

1. On a train with intermittent signal: a game that has already loaded keeps working, because nothing after the load needs the network. Do not reload the page until the signal returns.
2. Airplane mode before opening the game: it loads only if the browser has a usable cached copy. Opening it once while connected, shortly before, makes that more likely but does not guarantee it.
3. A game that installs as an app or says it works offline: it has a service worker and will keep working; the site made that promise deliberately.
4. Progress after being offline: unaffected. The record is on the device and never depended on the connection.
5. Switching devices: progress does not follow unless the game has accounts. Local storage is local.

Two things that help without changing the mechanics: keep a browser tab with the game open rather than reopening it, and avoid clearing site data for a site whose progress you want to keep. Neither is a substitute for a real offline design, but both work with the grain of how browsers already behave.

The common thread is that the browser, not the site, holds the keys. A site can make offline play likely by being small and by setting sensible cache headers, and can make it certain only by taking on the service worker work. Everything in between is weather.

What to read next#

How a loaded game keeps running between frames is described in why browser games feel smooth.

If the question behind the offline question is whether the time spent playing does anything beyond the game, the research overview on puzzle games and the brain gives the cautious answer.

Or test the mechanics directly: open Arrow Escape, let level 1 load, switch the connection off, and play on. The board is already on the device, and so is every rule the game applies to it; the only thing the network was ever needed for was delivering the file, once.