A game you can share as a link has a smaller barrier to entry. Browser ports also give communities another way to keep older software usable.
This started with a screenshot of 25 links to browser games. I turned it into a browser arcade, with artwork, search, and filters. The page is a directory. The linked projects do the work of running the games.
The interesting part sits behind the play button. How does code written for a desktop end up inside a browser tab? And does that give players more control?
The game can run on your machine
For a port that runs locally, the browser downloads the program and its assets. Your device then runs the game logic. This differs from cloud streaming, where a remote machine renders the game and sends you video.
WebAssembly makes many of these ports possible. It is a portable binary format that compilers can target. A browser can run the compiled code alongside JavaScript. C and C++ projects can therefore reuse substantial parts of their existing code.
That does not make every desktop executable a browser game. A port needs suitable source code, compatible libraries, and replacements for desktop facilities. Performance also depends on the program and the device.
There are other routes. Chrono Divide describes itself as a fan project that recreates Red Alert 2 using web technologies. Rebuilding a game for the web and compiling an existing engine are different engineering jobs. They can both end with a link you can open.
A small example of the compiler route
Emscripten is a toolchain for compiling C and C++ to WebAssembly. It also supplies runtime support for browser execution.
Here is the smallest useful example. Save this as hello.c:
#include <stdio.h>
int main(void) {
puts("Hello from a browser tab");
return 0;
}With the Emscripten SDK installed and active in your shell, compile it and serve the output:
emcc hello.c -O2 -o hello.html
python -m http.server 8000Open http://localhost:8000/hello.html. Emscripten produces an HTML page, JavaScript support code, and a .wasm file. The HTTP server lets the browser fetch those files.
This example shows the compilation path. A game adds rendering, input, audio, asset loading, and often networking. Those parts need their own porting work.
The browser has a different idea of a running program
A desktop game often owns a loop: read input, update the world, draw a frame, repeat. A browser must also handle page events and other work.
An endless blocking loop can freeze the page. Emscripten provides callbacks such as emscripten_request_animation_frame_loop() so the game runs one frame and returns control. Its runtime documentation explains this change and its browser input bindings.
| Desktop expectation | Work a browser port needs |
|---|---|
| Keep running inside the game loop | Schedule each frame through a browser-compatible loop |
| Read keyboard and mouse input | Connect browser events or supported Simple DirectMedia Layer (SDL) input APIs |
| Open files through operating system paths | Load assets into an accessible virtual file system |
| Use a desktop graphics API | Adapt rendering to browser graphics support |
For graphics, Emscripten can map supported OpenGL functionality to WebGL, a browser graphics API. Its OpenGL support guide documents the supported paths and their limits. The compiler cannot make every graphics call work unchanged.
Touch controls are another design job. A game can load on a phone and still require a keyboard. A responsive directory helps people find games, but it cannot fix the controls inside an external port.
A save file needs somewhere to live
The default Emscripten file system, MEMFS, stores files in memory. Reloading the page loses those changes. A working save button therefore does not prove that a save will survive your next visit.
IDBFS can persist data through IndexedDB, a database provided by the browser. The application must manage synchronization, or configure automatic persistence. The file system API documentation explains both options.
This matters for ownership. I would want a port to offer save export and import. A file I can carry to another build gives me more freedom than progress tied to one website.
Multiplayer still needs a network design
Browser code cannot simply open the same raw TCP or UDP sockets that a desktop engine uses. Ports need browser networking APIs, protocol changes, or a bridge. Emscripten’s networking guide describes WebSockets and server-side proxies, among other options.
Cloudflare’s multiplayer Doom experiment makes the split concrete. WebAssembly runs the game in the browser. WebSockets connect players, while Workers and Durable Objects handle multiplayer coordination.
The client runs locally, but that implementation still depends on hosted infrastructure. Moving computation into a tab does not remove the server bill or give players control of the service.
Access improves before ownership does
A link removes some familiar friction. You can try a compatible game without finding the right installer or setting up a desktop runtime. Sharing it with a friend becomes easier. A developer can distribute a browser build alongside native releases.
That is a useful step toward democratizing access. It broadens the ways people can reach software, including people who cannot install applications on the machine they use.
The limits remain practical. You still need a supported browser, enough memory, and a connection for the initial download. Large asset bundles can be expensive on limited data plans. Older phones may struggle. Accessible controls and readable interfaces still require deliberate work.
The browser also supplies an execution boundary. WebAssembly code runs in a sandbox and accesses host facilities through exposed interfaces. The WebAssembly security model describes that boundary. It does not promise that every game website respects your privacy or treats your data well.
Decentralization means someone else can keep it running
I use a stricter test for decentralization: can the software continue without the original website operator?
A browser build helps when its license permits redistribution and another person can host it. Available source code and build instructions let a community repair the port. Exportable saves let players move. Multiplayer needs compatible independent servers if players are to choose who runs their sessions.
These are separate decisions. An open client with one mandatory closed server still leaves that server operator in control. A static download hosted by several people can distribute delivery while keeping multiplayer centralized.
Game engines and game assets also have different permissions. The Quake source release puts the engine under the GPL, while its README says the original game data remains copyrighted under its original terms.
DiabloWeb shows this distinction in a browser port. It builds on Devilution and offers a shareware path. Playing the full game requires the player’s own DIABDAT.MPQ file from an original copy.
Open engine code can help preserve and adapt a game. It does not automatically make the art, music, or levels free to redistribute. Any community mirror has to respect those separate permissions.
The same route works for software beyond games
FFmpeg.wasm brings audio and video processing into the browser through WebAssembly. An application can process a file on the user’s device instead of sending it to a conversion service. Whether it actually avoids uploads depends on the application’s design.
SQLite’s WebAssembly build brings a familiar database engine into browser applications. That gives developers another building block for tools that work with data on the user’s machine.
Both examples change where useful computation can happen. A developer can make a tool available through a URL while keeping more work local. Open code, portable data, and usable offline builds can then reduce dependence on a single provider.
This is why browser ports feel like a step forward to me. They create another distribution route for games and software, and another place where communities can maintain them.
Start with a game in the arcade. Look for its source repository, its build instructions, and its asset requirements. Then check where saves and multiplayer sessions live. Those details show how much control the link actually gives you.