PS2 Web Recomp explained: how it runs PS2 games in a browser, and what works today

What "static recompilation" means here

A conventional emulator reads a game's machine code while the game runs and interprets or just-in-time compiles it. PS2 Web Recomp does the main part of that work ahead of time. Its eerecomp tool reads the game's executable, follows its control flow to find functions, and emits C++ for them in units of 16 KiB of guest code [1]. That C++ is compiled to WebAssembly, so the PS2's main CPU (the Emotion Engine) is never interpreted in the browser [1].

Everything else is emulated by a runtime:

• A small PS2 kernel. The main CPU's side of the operating system is answered by high-level emulation, while the I/O processor runs the game's own driver modules on an interpreter of its R3000 CPU [1].
• Vector units. Microprograms the game uploads to vector unit 1 are compiled ahead of time when seen during test runs, and translated to WebAssembly on the spot when first met in the page [1].
• Graphics. The Graphics Synthesizer's video memory lives on the GPU and drawing is done by WebGPU compute shaders [1].
• Sound and movies. The SPU2 sound chip is reimplemented, and movies are decoded by an implementation of the PS2's MPEG-2 decoder [1].

The author is clear that floating-point results can differ from the console's in the last bit, because the console truncates where the host rounds [1]. This is a careful reconstruction, not a bit-perfect copy of the hardware.

What works today

As of the README version we read, two games have been brought up [1]:

The author sets expectations plainly: another game will most likely stop at a system call or I/O library function nobody has implemented yet, or use a graphics feature the renderer does not handle [1]. The README also describes support for games that rewrite their own code at runtime, using Kingdom Hearts II's boot and menu module swapping as the example [1]. That describes a technique, not a claim that Kingdom Hearts II is playable.

The repository is being updated often (the last push before our check was on 18 October 2026) [3], so this table can go out of date quickly. We re-check this page at least every three weeks.

What you need to try it

This is a developer project, not a one-click app. The README lists:

• git, CMake, Ninja, a C++20 compiler (clang preferred), Python 3, and 7-Zip if your image is a .7z [1].
• Linux on x86-64 is where everything has been run; the scripts also build on macOS on Apple silicon with a newer bash from Homebrew [1].
• The first run installs the Emscripten SDK, and a native build downloads wgpu-native [1].
• About 300 MB of disk space per game for generated code and builds [1].
• A browser with WebGPU. Chrome and Edge have it on Windows and macOS; on Linux you must enable two Chrome flags. Without WebGPU a software renderer takes over that the author calls far too slow for 3D [1].

The port.sh script takes a disc image (an ISO, or a ZIP or 7z holding one), translates the boot program, runs the game headless a few times to discover code that static analysis missed, and builds both a web page and a native runner [1]. The author reports God of War II going from ISO to page in three and a half minutes on an 8-core laptop [1].

The README's requirements list a disc image of a game you own. It does not list a BIOS file among them [1]. We do not link to any game images or system files, and you should not download them from anywhere.

The legal line, in the author's words

The project draws a firm boundary, and it is worth following exactly [1]:

• The repository contains only original code and third-party code under its own license, and no game code or data.
• The generated C++ and the built WebAssembly are translations of the game's executable, so they belong to the game's owners. Keep them on your own machine and do not publish them.
• Use disc images of games you own.
• Anyone who can reach the server can load the game, so keep it to yourself.

In practice that rules out the obvious misuse: hosting a public page that streams a commercial PS2 game to strangers. It also means you should be wary of any website that offers to let you "play PS2 games online" using this name. The project itself does not run such a site; it gives you scripts to run locally [1].

The README names Gran Turismo, God of War and PlayStation as trademarks of Sony Interactive Entertainment and states the project is not affiliated with or endorsed by Sony or any publisher [1].

Why people are paying attention

The project drew wide interest after its Show HN post on 12 October 2026 [4], and the repository passed a thousand GitHub stars within days of being created [3]. The interest is less about playing two games in Chrome than about the method.

The README's account of performance work is unusually detailed. The first race ran at 3 frames per second natively. Moving graphics to WebGPU compute shaders and compiling vector unit programs brought it to about 70, and most of the remaining work was about where the browser spent its time [1]. Examples include cutting GPU dispatches per frame from about 650 to about 80, and a 16 MB GPU-side cache that cut the data sent per frame by about 60 percent in Gran Turismo 4 [1].

The second game was the real test of the approach. God of War II needed no game-specific code, but it exposed a recompiler bug at the boundary between code units and a vector-unit timing bug that Gran Turismo 4 never triggered [1]. Each new game is likely to surface more of these, which is why the honest answer to "will my game work?" is "probably not yet".

Saves and local hosting

The page puts a memory card in slot 1 and keeps it in the browser's storage for the address you play from, so progress survives a reload. An Export card button downloads it as a .ps2 file in the layout PCSX2 uses, and Import card loads one back [1]. That makes it possible to move a save between this project and PCSX2.

Because the page uses SharedArrayBuffer for threads, it must be served cross-origin isolated, with Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp. The included scripts/serve.py sends both headers and supports the HTTP Range requests the disc streaming relies on [1]. Keep that server on your own machine or private network, as the author asks.

There is also a native runner that plays the game in a window using SDL2 and wgpu-native on Vulkan, with the same memory card format [1].

FAQ