How Do Browser Games Run PS2 Code? WebAssembly and WebGPU Explained

A project that runs PlayStation 2 games inside a browser tab reached 313 points and 158 comments on Hacker News in the week of October 12, 2026 (the thread read four days old when we checked on October 16). The Show HN post, from the author deadxwarrior, links to the ps2-web-recomp repo on GitHub. The README says it runs PS2 games "without an emulator."

That claim started a fight, and the fight is useful. It is a good excuse to answer a plain question many readers ask: how do browser games run this kind of heavy code at all? In this guide we explain WebAssembly, WebGPU, and threads in simple words, then use the PS2 project as a worked example. We also mark which numbers are the author's own claims, because we did not run the project ourselves.

If you only care about playing free games in a tab, jump to our guides on friendslop browser games and browser games to play with coworkers. This post is for the "how does it work" crowd.

TL;DR: browser game tech in one table

What did the PS2 browser project actually do?

According to the author's post and README as summarized from the Hacker News thread, the pipeline works in four steps. You give it a disc image you own. It translates the game's main processor code into C++. It compiles that C++ into WebAssembly. Then the game runs in the browser and draws with WebGPU.

The author says the conversion happens on your own machine and that nothing taken from the game is hosted. That detail matters for the legal side, which we cover below.

The author also shared speed claims. These are claims from the thread, not tests we repeated:

• God of War II reportedly holds 60 fps at native resolution on a laptop with an integrated GPU.
• Texture sampling in the graphics-chip emulation takes about one third of GPU time.
• The vector unit code and the graphics front end each take roughly one quarter of CPU time, so they run on separate threads.
• Two big speedups: fixing synchronous GPU readbacks and batching many small draw calls.
• The Steam Deck target is 1x resolution, because that GPU is much weaker.

Treat the 60 fps line as "promising and unverified." One game on one laptop does not tell you how the library of PS2 games would behave.

How can WebAssembly run game code so fast?

JavaScript is a language the browser reads and optimizes while it runs. It can be fast, but it is hard to predict. WebAssembly is different. It is a low-level binary format. A compiler turns C, C++, or Rust into WASM ahead of time, and the browser turns that into machine code quickly and safely.

For games, this means three things:

1. You can bring old engines. Decades of C and C++ game code can be compiled for the web without a full rewrite.
2. Speed is steadier. Heavy loops such as physics, audio mixing, and decoding run closer to native speed than the same logic in plain JavaScript.
3. It stays sandboxed. WASM cannot touch your files or system unless the page gives it a narrow path.

There is a trade-off. WASM does not draw anything on its own. It has no direct access to the screen, the controller, or the sound card. It calls into browser APIs for all of that, and each crossing between WASM and the browser has a cost. Game ports spend a lot of effort making those crossings rare.

One more honest point: for plain 2D games and many 3D games built with JavaScript libraries, WASM is not needed. A commenter in an older Hacker News thread about a multiplayer voxel browser engine argued that JavaScript often beats WASM for rendering code, and that WASM mostly shines when you port an existing engine. That fits what we see: WASM is the "bring your old code" tool.

What is static recompilation, and why did people argue about it?

Normal emulation reads the old console's machine code one instruction at a time and pretends to be the old chip. That costs speed, because every instruction goes through a translation step at runtime.

Static recompilation does that translation once, ahead of time. You turn the old machine code into new code (here, C++ and then WASM) and run that directly. The same idea powered the Mario Kart Wii PC port we covered in August.

The Hacker News argument was about the label. Commenters said the PS2 project still emulates large parts of the console, so calling it "not an emulator" is a stretch. Specific points from the thread:

• The I/O processor still runs through an interpreter for now (the author says so too).
• Finding which functions to translate uses a discovery run: the game runs headlessly and the tool records function addresses it sees. A commenter called this heuristic.
• Vector unit programs are compiled ahead of time when found during discovery, and compiled in the browser (JIT) otherwise.
• Timing is not cycle-accurate. The author says it uses an approximate cycle budget and that most games sync on interrupts.

bunpav's take: both sides have a point. The CPU code is recompiled, which is the fast part. The graphics chip and other hardware are still emulated, which is the hard part. "Hybrid" is a fairer word than either extreme.

Why does WebGPU matter for games?

Graphics in a browser used to mean WebGL, which is based on a design from the OpenGL era. WebGPU is the newer API. It is closer to modern graphics systems such as Vulkan, Metal, and Direct3D 12.

For game developers, the practical gains are:

• Lower overhead per draw call. You can send more work with less CPU cost.
• Compute shaders. The GPU can run general code, which helps with particles, physics, culling, and effects.
• Better control over memory and pipelines.

Browser support has grown. One guide we found says Safari 26 shipped WebGPU in September 2025 across Apple platforms, while other sources say Firefox support is still rolling out on some platforms. Support differs by device and version, so check the official browser support tables before you ship. Most engines still treat WebGPU as optional and keep WebGL2 as the base.

The PS2 project is a good example of why WebGPU helps. Emulating a console graphics chip means a lot of small, odd draw operations. The author said batching those draws and removing synchronous readbacks (where the CPU waits for the GPU to hand back data) gave major wins. Both fixes are about reducing the cost of talking to the GPU, which is exactly where a newer API gives you room.

A fun cousin of this is the soft-body UI library we covered in Jelly UI and Hacker News. That story also touched a WebGPU demo, and it shows how far browser graphics have moved beyond flat pages.

Why do browser games need threads, and why is that hard?

Heavy ports need more than one CPU core. The PS2 author splits the vector unit and graphics front end onto separate threads. In a browser you do this with Web Workers and SharedArrayBuffer, which lets threads share memory.

The catch: browsers only allow shared memory on pages that are "cross-origin isolated." Your server must send two specific headers. That breaks some embeds, ads, and third-party scripts. Many small game portals skip threads for this reason, and it is one reason the best browser games are often single-thread friendly.

Other limits you will hit in any big web port:

One commenter on the PS2 thread joked that the port might miss Japanese titles that use the circle button to confirm, which is a small but real example of input mapping detail.

Can browsers run multiplayer games?

Yes. Three technologies matter:

• WebSockets: simple two-way connections to a server. Good for turn-based and casual real-time games.
• WebRTC: peer-to-peer data channels, also used for voice and video. Good for small rooms.
• WebTransport: a newer option for lower-latency data over modern HTTP. The multiplayer engine Ambient used it, alongside Rust, WASM, and WebGPU, according to its Show HN post.

Latency and cheating are the real costs. Because the client code is visible to the player, servers must be the source of truth. This is why browser multiplayer is strongest in party games, co-op, and quick sessions. For that side of the story, see no-download team building games, and the free-to-play angle in Dear Passengers' browser alternative.

Is it legal to run console games in a browser like this?

We are not lawyers, so read this as a news summary, not advice. The author says users bring their own disc image, and that the project does not host anything derived from the game. The author also said distributing a built game is not something they can do.

Commenters still raised two concerns: copyright status of the games and takedown risk. Another asked about hidden malware in community-built recompilations. A reply noted the source is at least open to review. If you try any project like this, build it yourself from a repo you read, and do not run binaries from random links. We also warned about fake emulator downloads in our PS5 emulation scam warning.

What does this mean for indie and browser game makers?

The lesson is not "put PS2 games on the web." It is that three layers have matured enough to do surprising work:

1. WASM for portable, fast logic.
2. WebGPU for modern drawing and compute.
3. Workers for parallel work, with some setup cost.

Smaller teams already use these pieces without fancy ports. A single dev can ship a 3D shooter built on three.js or a map-based game like Hop Earth with no download at all. Even government-run sites picked the browser as a distribution channel, as in ARCADE.GOV.

What should you do next?

1. If you are a player: try browser games first. They need no install, and you can test them on any laptop.
2. If you are a dev: start with WebGL2 and add WebGPU as an optional path. Check support tables before you promise anything.
3. If you want WASM: pick one hot loop (physics, pathfinding, decoding) and move only that. Measure before and after.
4. If you plan threads: set the cross-origin isolation headers early, and test with your ad and embed setup.
5. If you test a recomp project: read the repo, build locally, and use only discs you own.
6. If you see big fps claims: ask for the device, resolution, and game list. One data point is a demo, not a benchmark.

What are the caveats on this story?

Be careful with a few things. The 60 fps number, the thread split, and the profile percentages all come from the author's own post. We did not run the project. The Hacker News thread is a snapshot and comments will change. Compatibility across the PS2 library is unproven, and some commenters questioned the project's framing. We also saw some thread talk about AI-assisted development, which was mostly opinion and we do not rely on it.

Related reading

• Mario Kart Wii PC port: the recompiled game explained
• Jelly UI on Hacker News: soft-body web components
• Claude of Duty: a three.js FPS in the browser
• Hop Earth: drive real roads in a browser game
• ARCADE.GOV and the browser arcade
• Friendslop browser games
• No-download team building games
• Primary sources: Show HN thread, ps2-web-recomp on GitHub, MDN WebGPU API

Facts in this post are accurate as of October 16, 2026. Hacker News counts, project features, and browser support change often.