How HTML5 Browser Games Work

An HTML5 game is a web page with a drawing surface and a loop. That is genuinely the shape of it. This article walks through what happens from the moment you click a link to the moment the cat jumps, in the order it actually happens.

Step 1: the page arrives

Your browser requests the page and receives HTML - the document structure, the headings, the instructions, the buttons. At this point there is no game, but there is already something useful on screen: on a well-built game page, the title, the controls and the explanation are all real HTML that exists before any JavaScript runs.

That matters for two reasons beyond politeness. Search engines read HTML and cannot see inside a game. Screen readers do the same. A game page where the only content is a canvas is, to both of them, an empty page.

Step 2: the Canvas element

Somewhere in that HTML is a <canvas> element. It is a rectangle with a width and a height and nothing else - no contents, no structure, no meaning. The browser hands the game a drawing context for it, and from then on the game paints pixels into it directly.

Canvas is immediate mode: you issue drawing commands and they take effect immediately, and nothing is remembered. There is no list of objects the browser is tracking. If you draw a cat and then want it one pixel to the right, you clear the whole canvas and draw everything again. That sounds wasteful and is in fact extremely fast, because it is exactly what a graphics card is built to do.

The consequence for accessibility is significant and is covered in Canvas games explained: because the canvas has no structure, nothing inside it can be read by assistive technology. Anything meaningful has to exist outside it in real HTML.

Step 3: the game loop

The heart of every game is a loop that runs once per displayed frame. In a browser it is scheduled by requestAnimationFrame, which asks the browser to call your function just before the next repaint. Each pass does the same three things:

1. Measure elapsed timeHow long since the last frame? Typically about 16.7 milliseconds on a 60Hz display, and about 8.3 on a 120Hz one. Every movement in the game is multiplied by this figure.
2. Update the worldApply gravity, move objects, check collisions, add score, spawn and remove things. No drawing happens here at all.
3. Draw the worldClear the canvas and paint everything in its new position. No game logic happens here at all.

Keeping update and draw separate is not stylistic. If drawing code changes game state, the game behaves differently depending on how often it is drawn, which produces bugs that only appear on certain hardware and are miserable to track down.

Why elapsed time matters so much

A naive game moves the cat by a fixed number of pixels each frame. On a 60Hz display that is 60 steps per second; on a 120Hz display it is 120, and the game runs at double speed. This is the single most common bug in amateur browser games, and it is entirely avoided by multiplying every movement by the elapsed time.

Doing that means speeds are expressed in pixels per second rather than pixels per frame, and the game behaves identically everywhere. It also means the elapsed time must be clamped: if you switch tabs for thirty seconds, the next frame reports a thirty-second gap, and moving everything thirty seconds forward in one step would teleport the cat straight through a wall. Clamping the step to something like a twentieth of a second prevents that.

Step 4: input

Browsers deliver input as events - keydown, keyup, pointerdown, touchstart - which arrive whenever they happen, not on the game's schedule. Games therefore record events into a state object and read that state during the update step.

Two distinctions matter. Held state answers "is the left key down right now", which is what you want for movement. Pressed state answers "was the jump key pressed during this frame", which is what you want for actions that should happen once. Confusing the two produces a cat that jumps continuously while the button is held.

Touch adds its own requirements: a game has to call preventDefault on touch events while playing, or a swipe will scroll the page underneath the game, and a double tap will zoom it.

Step 5: audio

Sound uses the Web Audio API, which can generate tones directly rather than playing files. A jump sound can be a square wave sliding from 330Hz to 620Hz over a tenth of a second - a few lines of code and no download at all. Every sound in the games on this site is made that way.

One rule constrains all of it: browsers will not let a page produce sound until the user has interacted with it. This is a deliberate protection against pages that blare at you on load. In practice it means the audio system is created on the first click or key press rather than when the page loads.

Step 6: saving

High scores go into localStorage, a small key-value store attached to the site and held on your device. It is not sent anywhere, which is why a browser game can save your score without asking who you are.

It can also fail. Private windows discard it, some browser settings block it, and in certain contexts simply reading it throws an error. A game that assumes storage works will fail to start for those users, which is why every read and write should be wrapped in error handling and the game should run perfectly well with no saved data at all.

What HTML5 replaced

Before this stack existed, browser games ran in plugins - most famously Flash. A plugin was a separate piece of software the browser handed the page over to, which meant it had its own security surface, its own performance characteristics, and its own update cycle. Browsers no longer support these plugins.

What replaced them is not one technology but the combination described above: Canvas for drawing, requestAnimationFrame for timing, the DOM event system for input, Web Audio for sound, and localStorage for saving. "HTML5 game" is shorthand for a game built on that combination rather than the name of any single thing.

Key Takeaways

• A browser game is a web page containing a canvas and a loop that updates and draws once per frame.
• Canvas is immediate mode - the whole scene is cleared and repainted every frame, and nothing inside it has structure.
• Every movement must be multiplied by elapsed time, or the game runs at different speeds on different displays.
• Input arrives as events and is recorded into state; held state and pressed-this-frame state are different things.
• Sound can be synthesised with no files at all, but cannot start until the user has interacted with the page.

Frequently Asked Questions

Is an HTML5 game the same as a JavaScript game?

In practice yes. HTML5 describes the platform features - Canvas, audio, storage - and JavaScript is the language that drives them.

Do HTML5 games need a game engine?

No. Every game on this site is written in plain JavaScript with no framework. Engines help with larger projects; for a small arcade game they add more weight than they save.

Why do some browser games stutter?

Almost always because something else is occupying the browser's main thread - another tab, an extension, or an advertising script. The drawing work in a small game is trivial by comparison.

What is requestAnimationFrame?

A browser function that schedules your code to run just before the next repaint. It matches your loop to the display's refresh rate and pauses automatically when the tab is hidden, which saves battery.

Can HTML5 games use a gamepad?

Yes, through the Gamepad API, though support and button mapping vary between browsers and controllers. Most small browser games stick to keyboard and touch.

Are HTML5 games slower than native apps?

For small 2D games the difference is irrelevant - the browser is not the bottleneck. For large 3D projects the gap becomes real, which is why the format suits arcade games particularly well.