If you are evaluating engines for a web game, the default recommendation you will get is Unity, and the default reason is "it's the industry standard." That is true and mostly irrelevant to the question you are actually asking.
I have shipped web games both ways. This is the comparison I wish someone had given me — including the parts where Unity is genuinely the right answer, because there are several and pretending otherwise would make the rest of this untrustworthy.
The thing that decides it: are you targeting the browser, or exporting to it?
This is the whole argument, so I will put it first.
Unity's WebGL support is an export target. You build in an editor designed for native platforms, then emit a browser build. The web is a destination, not the native habitat. Everything downstream of that decision — bundle size, load time, how you debug — follows from it.
A web-native stack (Three.js, PixiJS, plain TypeScript) treats the browser as the primary platform. The thing you develop in is the thing users run.
If the browser is one of five platforms you ship to, Unity's export model is a reasonable trade. If the browser is where your players actually are — an instant-play game, a playable ad, a web-first F2P title — you are paying the export tax on every single build for a capability you are not using.
Where the web stack measurably wins
Bundle size and time-to-first-frame. A Unity WebGL build ships an engine runtime before it ships your game. Your first-load payload includes a large WASM binary whether your game is a puzzler or an open world. A Three.js/PixiJS build ships roughly what you wrote plus the libraries you imported, and code-splits like any other web app.
This matters disproportionately because web game players do not wait. Every second of load costs you a measurable share of your funnel, and on a mobile connection an engine-runtime-first payload is a real conversion problem. If your acquisition depends on instant play, this alone can decide the stack.
Iteration speed. Web reload is sub-second. No editor domain reload, no build step between "change a number" and "see the number." Over a tuning-heavy day — which is most days on a live game — this compounds into hours.
Live ops without store review. This is the one that surprises people who have not shipped F2P. An engine game ships a balance change through a binary build and store review. A web game pushes JavaScript and assets over the air in minutes. When you need to fix a broken economy on a Saturday, "minutes" and "a week" are different businesses. Wrapping with Capacitor and delivering updates over the air via Capawesome gets you native store presence and keeps the fast path.
Debugging is just the browser. Chrome DevTools, real heap snapshots, a real network panel, real profiling — the same tooling the entire web industry sharpens every year. Nothing engine-specific to learn.
AI agents can actually read your project. This is newer and, I think, the most underrated item. A web game is plain TypeScript in plain files, which is the format LLMs are strongest at and have seen the most of. A Unity project lives in binary scenes, serialized YAML, meta files, and editor state that an agent cannot reliably read or write. If a meaningful share of your output now comes from coding agents, project format stops being a detail and becomes a throughput ceiling. We wrote up the full web-native F2P stack and the iteration-speed argument behind it if you want the long version.
Where Unity genuinely wins — and you should pick it
I would be wasting your time if I did not write this section properly.
Existing team expertise. If your team knows Unity, that beats every architectural argument on this page. Retraining costs more than the export tax. This is the single most common correct reason to choose Unity and it is not a cop-out.
3D-heavy, near-native visual ambition. Advanced lighting, complex physics, large streamed worlds — Unity's renderer and tooling are years ahead, and Three.js will cost you significant custom engineering to approach it.
The asset store and middleware ecosystem. Genuinely enormous. Need an inventory system, a dialogue tree, a specific mobile ad SDK integration? On Unity you buy it this afternoon. On the web you write it.
Real multi-platform reach. Console, XR, native mobile with heavy device integration. This is not the web's fight and web advocates should stop pretending it is.
Complex editor-driven content workflows. Scene composition by level designers who are not engineers is something Unity's editor does well and a code-first stack does badly by default.
The honest summary: Unity is the better engine. The web is the better platform for web games. Those are compatible statements, and confusing them is what makes this debate so tedious.
The gap you will hit, and where it actually is
Assume you pick the web stack. Rendering is solved — Three.js for the world, PixiJS for the UI layer on top, both mature.
The gap is VFX authoring, and it is worth knowing about before you commit rather than discovering it in month three.
In Unity you have a visual particle editor. Your VFX artist opens it, tunes a curve, sees the result, hands over a prefab. On a bare web stack, "authoring particle effects" often means an engineer typing numbers into a config object and reloading — which means every VFX iteration costs engineering time, and your artist is blocked on someone else's calendar. That is an organisational bottleneck disguised as a tooling gap, and it is the one thing I would call a real regression versus Unity.
It is solvable, and closing it is why NixieFX exists: visual particle and material authoring in the browser, projects stored as plain JSON so a VFX change is code-reviewable like anything else, and an export bundle you load into Three.js with npm install nixie-fx three. The artist iterates and commits JSON; no engine build, no programmer in the loop. If you want the argument for why the classic engine era is ending for F2P specifically, we made that case at length.
Disclosure: I work on NixieFX. The Unity-wins section above is not false modesty — if you are building a 3D console title with a Unity-fluent team, use Unity.
How to actually decide
Skip the engine debate and answer three questions:
Is instant play in a browser core to how players reach you? If yes, weight load time heavily, and the web stack wins on that axis alone.
Does your team already know Unity? If yes, that is probably decisive, and that is fine.
How often do you need to change live content? If the answer is "weekly or faster," over-the-air updates are worth more than renderer features.
You do not need Unity to ship a browser game. You might still want it — but it should be because of question 2, not because it is the default answer.
If you have shipped a web game at scale and disagree — particularly on the asset-ecosystem gap, which I think is the strongest remaining argument for Unity — I would genuinely like to hear where this framing breaks down.
