How browser games actually work

Browser games used to mean Flash. You installed a plugin, the plugin ran the game, and when the plugin died in 2020 a decade of games went with it. What replaced it is not a plugin at all, which is the whole point.

The browser is the console now

A modern browser game is a web page. That is not a simplification, it is literally what it is: HTML, CSS and JavaScript, downloaded and run the same way any other page is. There is nothing to install because the thing that runs the game is already on your device.

What changed is what the browser can do. Three capabilities did most of the work:

• Canvas gives a page a rectangle of pixels it can draw into directly, sixty times a second, instead of laying out boxes of text.
• WebGL and WebGPU hand that drawing to the graphics card, which is how browser games got 3D that does not crawl.
• Web Audio made sound something you can schedule precisely rather than something you hope plays roughly on time.

Put together, a browser can now run a game loop that is structurally identical to the one in a native game: read input, update the world, draw a frame, repeat.

Why some browser games still feel slow

If the technology is that good, why do so many browser games feel sluggish? Usually not because of the game.

The most common cause is size. A game that ships fifty megabytes of textures has to download all of them before it can start, and on a mobile connection that is the entire experience. The second most common is the page around the game: portals that load six advertising scripts, three analytics tags and a video player before they get to the game itself.

This is why the platform you are reading this on does not load a game until you press play. Until then a game page is a picture and some text, which is why it opens as quickly as an article does.

What a game can and cannot do

A browser game runs inside a sandbox. It can draw, play sound, read your input, and store data under its own domain. It cannot read your files, see other tabs, or touch anything the browser has not explicitly handed it. When a game is embedded in a portal like this one, it is sandboxed a second time and given only the permissions it needs.

That sandbox is also why score submission works the way it does. A game runs entirely on your device, which means the score it reports is a claim, not a fact. Platforms deal with this by binding scores to a play session, capping implausible values and rate limiting submissions. It raises the effort required to cheat without pretending the problem is solved, because on the client it cannot be.

What this means if you build them

The constraints are the interesting part. You are writing for a machine you cannot inspect, over a connection you cannot predict, for a player who will leave if the first frame takes too long. That pushes you toward small assets, fast starts and simple loops, which is also a decent description of the games people actually keep playing.

If you are building one, the practical bar is low: a single HTML file, served over https, that works inside an iframe. Everything else is refinement.