wotlk-browser: A WotLK Client in a Browser With Your Own Game Data

By Indie Kings | October 21, 2026

Updated October 21, 2026: wotlk-browser is a same-day project that serves a World of Warcraft 3.3.5 client to a browser and tunnels the game's TCP connections to a real server. The repository was created on October 21, 2026, and by the time of check it had 3 stars, 1 fork, no releases and no open issues. It ships a WebAssembly client, a Node bridge, a MySQL account backend, and a README whose account manager section is headed "Account Manager (Untested)".

That last detail is the one to read twice. The project does not pretend to be finished. It also does not pretend to be a hosted realm: no realm server is included, and no play button leads to one. What it is, per its own README, is a delivery and connectivity layer. You slice your own game files, serve them over HTTPS, and point the tunnel at a server you already run.

Image: GitHub social preview for the wotlk-browser repository. Image credit: Pucur/wotlk-browser, via GitHub.

What the project actually is

The repository description is "World of Warcraft Client in Browser", and the README opens by calling it a browser-based delivery and connectivity layer for World of Warcraft: Wrath of the Lich King. The feature list names the pieces: web client delivery over HTTPS, game data streaming with block-based delivery and HTTP byte-range requests, a WebSocket-to-TCP tunnel, configurable routing, account management, session management, MySQL integration, diagnostics and logging, and environment-based configuration.

The architecture table splits the system into four parts. The web client is the browser-side code and its resources. The bridge server handles HTTPS file delivery, game data streaming and the WebSocket-to-TCP tunneling. The account backend handles authentication, registration and sessions. A MySQL-compatible database stores account and session data.

Nobody publishes a player count for this project, because it is not a realm. It is the plumbing a realm needs in order to live in a browser tab. The README is explicit about the prerequisites: a compatible Node.js runtime, the project dependencies, the necessary client files and game data, a configured MySQL database, valid TLS certificates for HTTPS deployments, and access to a compatible WotLK game server.

The client and the 17.8 GB of data you supply

The browser client is a WebAssembly build. The repository carries web/Wow.js at about 323 KB and web/Wow.wasm at about 8.7 MB, plus a loading font of about 62 KB, four loading images between 1.09 MB and 1.25 MB each, and a small art manifest. The JavaScript glue carries the marks of an Emscripten build, with references to SharedArrayBuffer and threads.

That binary is the smallest part of the job. The game data comes from the user. A manifest in the repository lists 195 data files with their sizes, and the total of those sizes is about 17.8 GB. The largest entry is Data/patch.MPQ at about 4.01 GB, followed by Data/lichking.MPQ at about 2.55 GB, Data/common-2.MPQ at about 2.44 GB and Data/common.MPQ at about 2.24 GB. Further down sit the English expansion speech archive at about 241 MB and the English backup archive at about 166 MB.

The README describes the pipeline in one line: the slicer cuts the enUS build into 64 KB chunks, written from the game folder into the blocks folder. The script behind it reads the manifest, matches each entry against the game directory, and cuts every file into chunks of 64 KB. The bridge then serves those chunks, and the page fetches the ones the client asks for.

Two prefetch lists sit alongside the manifest, one for the data the client reads on its way to the login screen and one for the data the client reads entering the world. The page fetches them in the background and warms the browser cache while the WebAssembly module downloads. A comment in the page notes that a stale list costs bandwidth rather than correctness, which is an honest way to describe a cache warm-up that can drift.

The bridge and its redirect default

The bridge is a Node program called bridge.mjs, and its configuration is entirely environment variables. The defaults in the source are a port of 443 and a bind address of 127.0.0.1, with the web directory, the game data directory, the statistics directory, the allowed realm hosts, the allowed realm ports, and the redirect rules all read from the environment.

The allowed ports are 3724 and 8085, the two a WotLK realm needs, one for authentication and one for the world connection. The allowed hosts default to 127.0.0.1, and the README's own examples show a comma-separated list of hosts the tunnel will accept, plus per-port redirects that send every connection on a port to a fixed address instead of the host the client asked for.

There is a default worth knowing about. The source sets the 3724 redirect to a fixed address, 51.254.7.68, unless the environment overrides it. The comment block above the code shows a different example value, and the README's second example shows a second redirect on 8085. Anyone deploying this should set the redirect variables deliberately rather than accept the shipped default, because an unnoticed redirect points realm traffic at a host the operator did not choose.

The bridge also sets the headers that make the WebAssembly client work. It sends Cross-Origin-Opener-Policy: same-origin and Cross-Origin-Embedder-Policy: require-corp, because the client's threads need SharedArrayBuffer, which browsers only expose to a cross-origin isolated page. It also sends Cross-Origin-Resource-Policy: same-origin and X-Content-Type-Options: nosniff, and it resolves game file paths case-insensitively while refusing to traverse above the game directory.

The account manager the README calls untested

The account section of the README carries a heading that is unusual in a project README: "Account Manager (Untested)". Anyone writing about this project should quote that heading rather than paraphrase it. The section below it describes a MySQL-backed account service with the usual endpoints for registration, a challenge, a login, a password change, an email change and account information, and it says responses are plain text, one value per line, with "OK" on success.

The login flow is a challenge and response, in the shape of the protocol the game itself uses. The client sends a username and receives a salt and the server's public value. The client computes its own value and a proof from the password, the salt and the server's value, and sends them back. On success the server returns a session token, which the other endpoints take. The code confirms the shape: a large fixed prime, a small generator, a multiplier constant, and SHA-1 helpers, all in one module.

Errors are as plain as the successes. The README shows a status code with a single-line reason, such as a wrong-password response or a username-already-taken response. The server module adds the details the README does not: the database pool, a challenge lifetime of 60 seconds, a session lifetime of 24 hours, and a ban table with its own start and end dates. A banned account is refused at login, and the account information endpoint reports the ban state as part of its output.

The same module records the things a private realm's operator needs to see. It tracks the last login time and the last IP for an account, the number of failed logins, and the expansion the account is set to, and it flags whether the account is banned. The admin page, which is a separate program, reads the event and session files the bridge writes and renders page loads, browser families, load failures by reason, and world sessions with their device, average session length and average frame rate.

The admin program requires an admin password, takes HTTP basic authentication, and listens on port 8081 by default. Its host default is 0.0.0.0, which is worth changing if the machine is not on a trusted network.

What the browser client demands

The page that loads the client is unusually explicit about its own limits, which is the most useful thing in the repository. It reports the reason a load failed rather than showing a blank screen.

WebGL 2 is required, and the page says so in plain words with a suggested fix: use a recent Chrome, Edge or Firefox on a computer. The page also refuses to run inside the built-in browsers of social apps, and it explains why in the code comment: those apps do not give the page a cross-origin isolated context, which the client's threads require. The page offers a link to open the realm in a real browser instead.

Phones are treated separately, with a lower memory ceiling of 2048 MB, a smaller game-data block cache, and a service worker so the realm can open without a connection. Opening the page with a stats parameter adds an overlay showing the frame rate, the WebAssembly heap size in megabytes and the viewport, which is a small sign the author debugs on real devices.

There is no shop and no browser-side account form. The page's own description says you create an account on the login screen, which is the native client's own screen, and the page's code comments point at the client's account code by name. Session state beyond the browser cache lives in the MySQL backend, not in the page. And the launcher download link that the Conquest of AzerothCore front page points at is still marked as coming soon, which is not this project's problem to solve: this repository is the layer underneath, not the realm in front of it.

FAQ

What is wotlk-browser?
A delivery and connectivity layer for World of Warcraft 3.3.5. It serves a WebAssembly client and the game data over HTTPS and bridges the browser's WebSocket connections to a real realm server over TCP.

Do I need my own copy of the game?
Yes. The manifest covers 195 data files worth about 17.8 GB, and the README says the slicer works on the enUS build from the user's own game folder. The repository ships no game data.

Is the account manager ready to use?
The README heads that section "Account Manager (Untested)". It describes registration, a challenge and response login, password and email changes, and account information, and the code adds session expiry, ban checks and failed login tracking. Read the heading as written.

What does the client need from a browser?
WebGL 2, a cross-origin isolated page for the client's threads, and a recent Chrome, Edge or Firefox on a computer. The page refuses to run inside social apps' built-in browsers and tells you to open it in a real browser.

Is there a server included?
No. The prerequisites list access to a compatible WotLK game server. This project is the layer that puts a client in a tab; it is not a realm and it does not run one.

What should I check before deploying it?
The realm host and port allowlists, and the redirect variables. The shipped source sets the 3724 redirect to a fixed address unless the environment overrides it, so a deployment that does not set it deliberately sends realm traffic somewhere the operator did not choose.

Our take: The interesting part is the honesty about the limits. A project with 3 stars and a same-day commit history that tells you its account manager is untested, names the exact browser requirements in the page, and ships a size manifest covering 17.8 GB of data you already own is a better-engineered starting point than most things with a launch trailer. The one thing to fix before you point it anywhere is that default redirect.

Bottom Line

wotlk-browser is an MIT-licensed Node.js project created on October 21, 2026 that puts a World of Warcraft 3.3.5 client in a browser tab. It serves a WebAssembly client and the user's own sliced game data over HTTPS, bridges WebSocket traffic to a realm's TCP ports, and ships a MySQL account backend whose own README section is headed "Account Manager (Untested)". It had 3 stars, 1 fork, no releases and no open issues at the time of check. It needs a WotLK 3.3.5 client the user already owns, a MySQL database, TLS certificates, and a realm server to reach, and its page demands WebGL 2 and a cross-origin isolated browser.

Sources

Pucur/wotlk-browser repository README, including the features, architecture, prerequisites, install steps, security notes and the account manager section, verified October 21, 2026.

The repository's own source files, bridge.mjs, server.mjs, admin.mjs, srp.mjs, web/index.html, web/game-manifest.txt and web/slicer.py, for the default configuration, headers, session and ban handling, the browser requirements, the 195-entry manifest and the 64 KB slicer, verified October 21, 2026.

GitHub repository metadata for Pucur/wotlk-browser, verified October 21, 2026: 3 stars, 1 fork, 0 open issues, JavaScript, MIT, created October 21, 2026, last push October 21, 2026.

Related: Lighthaven: A Full WoW 3.3.5a Client Boots in Your Browser With Nothing Installed | Open Vanilla: Vanilla WoW in a Browser Tab, Server and Bot Included