How to Make HTML5 Games in Python, C#, C++, Java, Lua, Haxe or TypeScript

A browser runs two kinds of code: JavaScript and WebAssembly. Any language that compiles to one of them can make an HTML5 game, and in October 2026 that covers Python, C, C++, C#, Java, Lua and Haxe, each with at least one maintained toolchain. The game still draws into a <canvas> with WebGL and reads the same browser input; only the path from your source code to the page changes.

That path has a cost. Most of these toolchains ship a language runtime or engine compiled to WebAssembly alongside your game, so the first download is bigger, and you debug through a compiler instead of reading your own code in the browser. We write our 50 games in TypeScript (41 on Phaser 4, 9 on Three.js) for exactly that reason. This guide covers the real options per language, what works today and where each one stops. For engines written in JavaScript, see our HTML5 game engine comparison.

Every language at a glance

Python: how to use Python to create HTML5 games

Python can't run in a browser natively, so every route ships a Python interpreter compiled to WebAssembly. Three are worth knowing.

pygbag packages a pygame-ce game for the web. Version 0.9.3 came out in February 2026 (PyPI). Install it with pip install pygbag, run pygbag your_game_folder, and it serves the game at localhost:8000; --build builds without the server and --archive writes a build/web.zip ready for itch.io. Your folder needs a main.py whose loop yields to the browser every frame:

import asyncio
import pygame

pygame.init()
screen = pygame.display.set_mode((640, 360))
clock = pygame.time.Clock()

async def main():
    x = 0
    while True:
        for event in pygame.event.get():
            if event.type == pygame.QUIT:
                return
        x = (x + 3) % 640
        screen.fill((20, 24, 40))
        pygame.draw.circle(screen, (255, 200, 0), (x, 180), 20)
        pygame.display.flip()
        clock.tick(60)
        await asyncio.sleep(0)  # hand control back to the browser

asyncio.run(main())

The pygbag docs list the browser rules that trip people up: use OGG for audio (not WAV or MP3), PNG, WEBP or JPG for images, match file name case exactly, and avoid synchronous network or file I/O (pygbag notes).

PyScript offers a py-game script type that loads pygame-ce for you; its 2026 docs call the feature "experimental but functional". The only change to normal pygame code is an await asyncio.sleep(1/60) in the loop. It suits a game embedded in a teaching page.

Pyodide is the CPython-in-WebAssembly project PyScript builds on. Use it directly when you want Python game logic driven from your own JavaScript.

All three download a full Python runtime before the game starts, which is fine for a game jam or a classroom and heavy for a game players find through an ad. If you want to build an HTML5 game with Python as a learning project, pygbag is the shortest path. If you want to ship a commercial web game, Python is the wrong tool for the client; use it on the server instead.

C and C++ HTML5 game engines

Emscripten is the standard compiler from C and C++ to WebAssembly. It is built on LLVM, maps OpenGL calls to WebGL, and supports SDL, POSIX APIs and pthreads, so a native game often ports with modest changes.

raylib, a C library for games, is the friendliest C HTML5 game engine to start with. Its web build guide) compiles the library with PLATFORM_WEB, links your game with emcc and -s USE_GLFW=3, and uses a small shell page. The one structural change is the main loop. A browser can't block in while (!WindowShouldClose()), so you hand one frame at a time to the browser:

#if defined(PLATFORM_WEB)
    #include <emscripten/emscripten.h>
#endif

void UpdateDrawFrame(void);   // update and draw one frame

int main(void) {
    InitWindow(800, 450, "My web game");
#if defined(PLATFORM_WEB)
    emscripten_set_main_loop(UpdateDrawFrame, 0, 1);
#else
    SetTargetFPS(60);
    while (!WindowShouldClose()) UpdateDrawFrame();
#endif
    CloseWindow();
    return 0;
}

The alternative is Emscripten's ASYNCIFY option, which keeps the blocking loop at some cost in speed and size. Either way, test through a local server (python -m http.server), because opening the HTML file from disk often fails.

SDL games port the same way, and Godot, an engine written in C++, exports to the web from its editor. Godot's web export docs (4.7) note the limits: the web uses the Compatibility renderer on WebGL 2, there's no WebGPU yet, and mobile browsers run it more slowly than native exports.

C#: Unity, KNI and Blazor

C# has three routes into the browser:

• Unity builds C# games for its Web platform. It's the mature option, with an engine runtime that makes downloads larger than a JavaScript game; our guide to Unity and Unreal for web games covers it in detail.
• KNI, an open-source re-implementation of the XNA Framework derived from MonoGame, targets web browsers with WebGL (repository). If you have an XNA or MonoGame codebase, this is the closest path; MonoGame itself has no official web target.
• Blazor WebAssembly runs .NET in the browser and can drive a canvas. It suits simple board, card or puzzle games inside a .NET web app. Microsoft's docs note that ahead-of-time compilation runs CPU-heavy code faster at the cost of a larger download.

One trap: Godot 4 supports C#, but its docs say C# projects cannot be exported to the web in Godot 4. Use GDScript in Godot if the browser is a target.

Java: how to make an HTML5 game with Java

Use libGDX. It's a mature Java game framework, and its official HTML backend compiles your Java to JavaScript with GWT. Generate a project with the HTML platform ticked, then:

• gradlew html:superDev runs the game on a local server with fast reloads and source-level debugging in Chrome.
• gradlew html:dist writes an optimized build to html/build/dist/, which you can upload to itch.io, GitHub Pages or any static host.

That answers how to put an HTML5 libGDX game on a website: upload the dist folder and link to its index.html, or embed it in an <iframe>. The libGDX wiki lists the limits of the HTML5 backend: no Java reflection (use libGDX's own reflection utilities), no multithreading, audio that starts only after a user interaction, and some Pixmap features missing.

A newer alternative is gdx-teavm, a third-party backend that compiles Java bytecode with TeaVM to JavaScript or WebAssembly. It avoids some GWT restrictions, but it's maintained by one developer, so weigh that before betting a commercial game on it.

Lua HTML5 game engines

Defold is the strongest choice. Its engine is C++ and your game logic is Lua, and it bundles to HTML5 from the editor (Project > Bundle > HTML5 Application) as a WebAssembly build (Defold HTML5 manual). Saves go to a virtual file system backed by IndexedDB, and the threaded build variant needs cross-origin isolation headers, so ship the non-threaded variant too unless you control your host. Defold is used for commercial web and mobile games and has an active team behind it.

LÖVE runs in browsers through love.js, a community port of LÖVE 11.5 built with Emscripten. Its default build uses threads and needs SharedArrayBuffer headers; its compatibility mode works in most browsers with weaker audio. It's fine for jams, less so for products.

Solar2D has an HTML5 export, but it is still labelled beta. And fantasy consoles such as PICO-8, which uses a Lua dialect, export HTML players for small retro games.

Haxe HTML5 game engines

Haxe compiles straight to JavaScript (and to native targets), so a Haxe game on the web is ordinary JavaScript plus source maps, without a WebAssembly runtime. The current stable release is Haxe 4.3.7, with Haxe 5 in preview (downloads). The main engines:

• Heaps: a 2D and 3D engine from the studios behind Dead Cells and Northgard, with HTML5 as one of its targets.
• OpenFL: a Flash-style display list API, which makes it the natural home for developers coming from ActionScript.
• HaxeFlixel: a 2D game framework built on OpenFL, popular for game jams and pixel-art games.

Haxe suits teams that want one codebase for desktop, mobile and web without a heavy runtime in the browser. The community is smaller than JavaScript's, so expect to read engine source when documentation runs out.

TypeScript HTML5 game engines

TypeScript is JavaScript with types, so every JavaScript engine works with it and nothing extra ships to the player. This is the route we use: our games are TypeScript projects built with Vite and tested with Vitest and Playwright. The engines with the best TypeScript support:

• Phaser: Phaser 4 ships TypeScript definitions generated from its source. It's our engine for 2D, and our Phaser tutorial starts from a typed scene.
• Excalibur: a 2D engine written in TypeScript from the start.
• Babylon.js: a 3D engine written in TypeScript.
• Three.js: typed through the community @types/three package; we use it for our 3D games.

import Phaser from "phaser";

export class PlayScene extends Phaser.Scene {
  private score = 0;
  private label!: Phaser.GameObjects.Text;

  constructor() { super("play"); }

  create(): void {
    this.label = this.add.text(16, 16, "Score: 0");
    this.input.on("pointerdown", () => this.addPoints(10));
  }

  private addPoints(points: number): void {
    this.score += points;
    this.label.setText(`Score: ${this.score}`);
  }
}

The compiler catches typos in method names and wrong argument types before you run the game, which matters more as a game grows. If you know C# or Java, TypeScript will feel familiar within days, and you keep the small downloads and direct debugging of plain JavaScript.

PHP and MySQL browser games

PHP can't run a game in the browser; it runs on the server. A PHP HTML5 game engine doesn't exist in that sense, but PHP and MySQL have a long history behind browser games:

• Classic browser games, the text-heavy strategy and management games where each action loads a new page, were typically written in PHP with MySQL. The model still works, but players now expect a JavaScript front end.
• Modern games split the work: an HTML5 client in JavaScript or TypeScript handles drawing and input, and a PHP API handles accounts, saves, inventories and leaderboards. That's a sound design for turn-based and asynchronous games.
• Real-time multiplayer needs a persistent connection, usually WebSockets. PHP can serve them with dedicated libraries, though many teams use Node.js for that part.

If you look for an open source PHP and MySQL HTML5 browser game to study, check how it validates moves on the server. Anything the client sends can be faked, so the server must check every action and use prepared statements for every query. Our guide to multiplayer HTML5 games covers server choices.

Which language should you use?

• You know Python and want to share a pygame game: pygbag.
• You have a C or C++ game: Emscripten, ideally with raylib or SDL already in place.
• You work in Unity: its Web build. With XNA or MonoGame code: KNI.
• You have a libGDX game: the GWT backend you already have.
• You like Lua: Defold.
• You're starting a game for the web from scratch: TypeScript with Phaser for 2D or Three.js for 3D. It loads fastest, embeds anywhere and has the most learning material. Our HTML5 game makers guide covers no-code options if you'd rather not program at all.

If you'd rather study a complete game than a toolchain, each of our games is a buildable TypeScript project with its tuning in JSON data files and its own tests. You can play all 50 games in the browser first, or start with the Phaser 4 catalog.

We make and sell HTML5 game source code; links to our games are marked as ours.