Click a thumbnail, wait two seconds, and a complete game is running inside a rectangle on a web page. No installer, no permissions dialog, no update to download. It feels like a small miracle if you remember the plug-in era, and it is worth understanding how it happens, because that understanding changes how you play — and how you judge a game before you press start.
What "HTML5 game" really means
The phrase is shorthand. A modern browser game is not written in HTML at all; it is written in JavaScript (or compiled to JavaScript and WebAssembly from a language like C# or C++), and it draws to a single HTML element: the <canvas>. The canvas is a blank bitmap that a script can paint on sixty times a second. Everything you see — the character, the score, the particle effects — is the result of code deciding, frame by frame, which pixels to colour.
Two drawing paths exist. The 2D context is a simple painter's API: draw this image here, draw that rectangle there. It is easy to program and fast enough for most casual games. WebGL is the other path: it talks to your graphics card directly and can render three-dimensional scenes with lighting and shaders. If a game takes noticeably longer to load and then runs a full 3D world, it is almost certainly using WebGL, often produced by an engine such as Unity or Godot exporting to the web.
Why Flash disappeared
For fifteen years browser games meant Flash. Flash was a plug-in — a separate program the browser handed the page over to — and that arrangement had three problems the web eventually could not tolerate. It was a security hole, because a single vulnerability in one plug-in exposed every site that used it. It was a battery hog on laptops and never really worked on phones. And it was owned by one company, which meant the open web depended on a closed product.
Between 2010 and 2020 browsers gained native equivalents for everything Flash did: canvas for drawing, the Web Audio API for sound, WebGL for 3D, WebSockets for multiplayer. Once those were reliable, browsers began blocking Flash by default, and in December 2020 support ended completely. Developers rewrote, ported or abandoned their games. The ones you play today are the survivors and their successors.
The loading moment
When you press play, the page loads an iframe — a window inside the window — pointing at the game's own files on a distribution server. The browser downloads the game's code, images and sounds, compiles the JavaScript, and starts the game loop. That loop is the heartbeat of every game: read input, update the world, draw the frame, repeat. A well-made game keeps this loop at a steady 60 iterations per second and never blocks it with slow work.
This is why a game can feel different on two computers. If the browser cannot finish a frame in 16 milliseconds — because another tab is busy, because the machine is old, because a browser extension is injecting scripts — frames are skipped and inputs land late. Nothing is wrong with the game; the loop is simply being starved. Closing heavy tabs and turning on hardware acceleration in your browser settings fixes more "laggy game" complaints than anything else.
Where your progress lives
Browser games cannot write files to your disk. What they can do is use the browser's own storage: localStorage for small key-value pairs, IndexedDB for larger data. Your high score, unlocked levels and settings are saved there, tied to the game's domain and to the browser profile you are using. Switch from Chrome to Firefox, clear your site data, or open a private window, and the game starts fresh. This is the single most common cause of "I lost my progress" messages, and it is not a bug.
Input: keyboard, mouse and touch
Games listen for the same events any web page can see: key presses, mouse movement, clicks and touch points. A game built for desktop usually reads WASD or arrow keys and the mouse. A game that also runs on phones adds touch handlers, often drawing virtual buttons onto the canvas. When our game pages say a title is "mobile friendly", it means the developer flagged touch support and the frame adapts to a small screen; when they say "desktop", it means the input model would not survive a thumb.
One quirk worth knowing: browsers require a user gesture before a page may play audio. That is why so many games open with a "tap to start" screen — the tap unlocks sound as well as starting the game.
Why this matters when you choose a game
Once you know the pieces, the signals on a game page make sense. A large "frame size" in the details table means a game designed for desktop resolutions. A long first load followed by smooth play suggests WebGL and a real engine. A game that saves progress will say so, and you will know to finish a level before closing the tab. None of this is hidden; it is just rarely explained. We think it should be.
