Physics Engines for Web Apps: 7 Options Ranked for 2026

TL;DR

• Rapier is a Rust/WASM option for 2D and 3D with continuous collision detection. The catch: asynchronous initialisation and a package/build choice to make.
• Matter.js is a friendly 2D starting point. The catch: 2D only, with performance to check on your own scene and device.
• Cannon-es is a Three.js community option. Measure the selected build and scene rather than assume one bundle size or body limit fits every project.
• Planck.js brings Box2D fidelity to 2D, Havok is the Babylon.js default, Ammo.js is a Bullet port, and Jolt is the emerging dark horse with a browser WASM wrapper.
• Most "simple" web effects (UI animation, parallax) need no physics engine at all. Only commit when you need real collisions or constraints.
• Consider Rapier for 3D physics with CCD; consider Matter.js for simple 2D interactions. Benchmark your actual scene before declaring a performance winner.

👉 Skip the guesswork on tool stacks: MoreMagpie shows how a physics engine fits with your renderer and build stack, join the waitlist.

So You Want Things to Move, Collide, or Fall on the Web

You described an idea to an AI builder. It said "use Rapier" or "use Cannon." No reason. No alternatives. Just a name.

That is the problem. A physics engine is a big commitment, and the first answer isn't the whole picture.

Here's what we'll cover:

• do you actually need one
• the 2D vs 3D fork
• 7 engines ranked
• how they compare at a glance
• which one fits your project
• how MoreMagpie helps

The right physics engine depends on two things most lists skip: whether you need 2D or 3D, and which renderer you are pairing it with.

Pick wrong early and you can lose weeks rebuilding. Pick right and the rest of the stack falls into place.

This post ranks the seven physics engines for web apps that actually matter in 2026, names the catch on each one, and ends with a plain decision table.

Do You Actually Need a Physics Engine?

Start here, because the honest answer is often "no." A physics engine is a library that simulates real-world forces, collisions, and constraints in real time. It is overkill for a lot of web work.

A full-featured physics engine is often unnecessary for simple applications with minimal or scripted interactions, such as basic 2D UI animations or static data dashboards (source).

When you don't need one: scroll effects, parallax, hover animations, simple drag-and-drop. CSS animations or a library like GSAP handle these with far less bundle weight.

When you do need one: rigid-body dynamics (things that fall, bounce, stack), collision detection between many objects, or constraint-based simulation (ropes, joints, vehicles).

Every physics engine adds bundle size and complexity. Commit only when scripted animation genuinely can't do the job.

2D or 3D: The Decision That Narrows the Field

This is the fork that matters most, and it comes before you pick a name. A 2D physics engine simulates motion on a flat plane: x and y, no depth. A 3D physics engine adds the z axis and simulates volume, which is heavier and more complex.

The difference is not cosmetic. It decides which engines are even on your shortlist, and which renderer you pair with.

2D engines (Matter.js, Planck.js) are smaller and simpler. They pair with PixiJS or plain HTML5 Canvas.

3D engines (Rapier in 3D mode, Cannon-es, Ammo.js, Havok, Jolt) pair with Three.js or Babylon.js.

So the common question "which physics engine should you use with Three.js?" already assumes 3D. For a Three.js scene, the practical choices are Rapier, Cannon-es, or Ammo.js.

One more thing worth saying plainly: the engine and the renderer are separate decisions. The tools are a separate decision from the look you want.

The 7 Physics Engines Ranked

We compare 2D or 3D scope, setup, documented features, and renderer fit. This is an editorial shortlist, not an equivalent-build performance benchmark; author-run methodology and results are not included in this article.

Here is the ranked list.

1. Rapier: Rust and WebAssembly for 2D and 3D

What it does: Written in Rust, compiled to WebAssembly. Handles both 2D and 3D. Supports continuous collision detection (CCD).

Stands out for: Rust and WebAssembly. Dimforge's January 2026 post reported that its fastest web npm package was 2x to 5x faster than its own fastest 2024 package. That is a dated, build- and workload-specific comparison, not a cross-engine winner. Rapier is not the only engine here with CCD: Planck.js, Ammo.js, and Jolt also expose options, with different limits.

Worth noting: The JavaScript and WASM payload depends on the selected package and build. Because it is WASM, it needs an async init step your AI builder has to handle. The API is newer, so there are fewer copy-paste tutorials than Cannon-es.

Pricing: Free, open source (Apache 2.0 / MIT).

Best if: You need 2D or 3D physics with CCD and can handle WASM setup. Check the renderer integration and actual scene before committing.

2. Matter.js: The Friendliest 2D Starting Point

What it does: Pure JavaScript 2D physics. Works with HTML5 Canvas, PixiJS, or standalone.

Stands out for: Near-zero setup and the largest beginner tutorial ecosystem of any engine here. If you are new to physics and want something on screen fast, this is the gentlest on-ramp.

Worth noting: Check body-count performance on your own scene and target browser. No 3D support. Pure JavaScript with no WASM, so the performance ceiling is real. Project maintenance has slowed since 2023.

Pricing: Free, open source (MIT).

Best if: You are building a 2D interactive experience, landing page, or simple game prototype and want the fastest path to working physics.

3. Cannon-es: The Three.js Community Standard

What it does: A community-maintained fork of the abandoned Cannon.js. 3D only. Built to pair with Three.js, where transforms sync naturally.

Stands out for: Tutorial coverage. Most Three.js physics tutorials are written against Cannon-es, so your AI builder will likely default here. Measure the selected package before comparing its download cost.

Worth noting: Check performance on your actual scene and device. No CCD support, so fast-moving objects can tunnel through walls (a known gap flagged in Three.js community threads). Maintenance is community-driven, not backed by a funded team.

Pricing: Free, open source (MIT).

Best if: You are adding 3D physics to a Three.js scene and want JavaScript physics alongside existing tutorials.

4. Planck.js: Box2D Logic in a JavaScript Body

What it does: A faithful JavaScript port of Box2D, the 2D engine behind Angry Birds and thousands of games. 2D only.

Stands out for: Deterministic simulation. Two clients running the same inputs produce identical results, which matters for turn-based or networked 2D games. Box2D's constraint solver is battle-tested.

Worth noting: Smaller community than Matter.js and fewer modern examples. Box2D itself reached stable release 3.1.1 on June 4, 2025, after a full C rewrite in 3.0 (source), so the underlying logic is actively maintained even if the JS port moves slower.

Pricing: Free, open source (MIT).

Best if: You need Box2D-level fidelity in the browser, or you are porting a 2D game that already uses Box2D logic.

5. Havok: The Babylon.js Default

What it does: An AAA-grade physics engine, now available as a WASM plugin for Babylon.js. Physics bodies attach directly to Babylon meshes, and transforms sync automatically (source).

Stands out for: Deep Babylon.js integration. No manual sync code needed, and simulation quality is AAA.

Worth noting: It is tightly coupled to Babylon.js. Using it outside Babylon requires significant glue code, so it is not the right pick if your renderer is Three.js. Commercial licensing can apply in some non-Babylon contexts, so check Havok's own site for your use case.

Pricing: Free for Babylon.js projects.

Best if: You are building a 3D experience in Babylon.js and want physics to just work.

6. Ammo.js: The Bullet Port, Warts and All

What it does: An Emscripten-compiled port of the Bullet physics library, the engine behind many AAA games and Blender's physics. 3D.

Stands out for: Bullet parity. If your team already knows Bullet, the mental model transfers directly.

Worth noting: Measure the JavaScript and WASM payload of the selected build. The API is a direct C++ port: verbose, low-level, and hostile to beginners. CCD is exposed through per-body settings; check those explicitly. Active development has largely shifted toward Rapier and Jolt.

Pricing: Free, open source (zlib).

Best if: You specifically need Bullet physics behavior or are integrating with an existing Bullet-based pipeline.

7. Jolt Physics: The Emerging Contender to Watch

What it does: A C++ physics engine (MIT license) by Jorrit Rouwe, listed as used in Horizon Forbidden West. Now available as a WASM wrapper for browser use.

Stands out for: A C++ foundation with listed production uses. Measure the selected browser build and scene before claiming a speed advantage; a native production credit is not a web benchmark.

Worth noting: The JavaScript wrapper ecosystem is early-stage as of 2026. Fewer tutorials, less community support, and more manual setup than Rapier or Cannon-es. Watch it, but don't ship a critical project on it yet.

Pricing: Free, open source (MIT).

Best if: You can trade more integration work for evaluating another C++/WASM option, or you want to evaluate Jolt for a future project.

Quick Comparison: All 7 Engines at a Glance

Here is every engine side by side. The table compares scope and features; measure the selected build and scene for each project.

CCD catch: Ammo exposes per-body CCD setters, Planck exposes bullet bodies, and Jolt LinearCast uses the starting rotation, so it does not eliminate every fast rotational tunneling case.

Which Physics Engine Should You Pick?

The physics engine is never the whole decision. Match it to your actual situation.

• Building a 2D interactive page or casual game, as a beginner: Matter.js. Fastest on-ramp, biggest tutorial pool.
• Adding 3D physics to a Three.js scene, want tutorials to exist: Cannon-es. Check the selected package and its tutorial coverage.
• Need 3D physics with CCD: Consider Rapier, then check its behaviour and performance against your chosen scene. Other engines here also have CCD options.
• Using Babylon.js: Havok. It is the default and syncs automatically.
• Porting a Box2D 2D game to the browser: Planck.js. Deterministic and battle-tested.
• Need Bullet physics behavior and accept the bundle cost: Ammo.js. Measure the selected build before accepting its download cost.
• Want to evaluate another C++/WASM option and can do integration work: Jolt. Try the actual scene and wrapper before choosing it.

One reminder: the engine pairs with a renderer and a build stack. That combination, not the engine alone, is what your AI builder actually needs in its brief.

How MoreMagpie Helps You Pick the Right Stack

Picking Rapier over Cannon-es is only step one. It still has to fit your renderer and the rest of your web stack, and that is the part most lists leave out.

See how the pieces connect: MoreMagpie helps non-technical founders and AI builders see how a tool stack fits together, covering web experiences with tools such as Next.js, Supabase, and Clerk. It explains what each tool does, why it helps, and how the pieces connect, so a physics engine plus a renderer plus your backend reads as one plan, not a list of names.

Compare approaches, not just one answer: The first answer isn't the whole picture. MoreMagpie helps you compare approaches, costs, and trade-offs for the same idea, for example Rapier versus Cannon-es for a Three.js project, so you see the options before you commit.

Know the catch before you build: For every suggested tool, MoreMagpie aims to show what it does, why it helps, how it connects, and the costs, limitations, and questions still to answer, like bundle size or missing CCD. It labels guidance as Documented (from official sources) or Tested (actually tried, with stated limits), so you always know what you are relying on.

MoreMagpie is early and currently gathering waitlist signups. Join the waitlist to bring your AI builder a clearer brief.

Frequently Asked Questions

What is a physics engine?

A physics engine is a software library that simulates real-world forces, collisions, and constraints in real time. On the web it calculates how objects fall, bounce, stack, and collide so you don't code the math by hand. It handles rigid-body dynamics and, in some cases, continuous collision detection.

What is the difference between a 2D and a 3D physics engine?

A 2D physics engine simulates motion on a flat plane using x and y axes only, which keeps it small and simple. A 3D engine adds the z axis and simulates volume, making it heavier and more complex. Your choice also decides your renderer: 2D pairs with PixiJS or Canvas, 3D with Three.js or Babylon.js.

Which 2D physics engine should I use?

For most web projects, use Matter.js. It has near-zero setup and the largest tutorial ecosystem, handling around 300 bodies at 60 fps. Choose Planck.js instead if you need Box2D-level determinism for networked or turn-based 2D games where identical inputs must produce identical results across clients.

Which physics engine should you use with Three.js?

Three.js is 3D, so your options are Rapier, Cannon-es, or Ammo.js. Cannon-es has the most tutorials and the smallest bundle at ~55 KB. Rapier offers far higher performance (2,000+ bodies) and continuous collision detection. Ammo.js only makes sense if you specifically need Bullet physics behavior.

Is Rapier good for multiplayer physics?

Yes. Rapier is a strong choice for multiplayer because it supports deterministic simulation, meaning the same inputs produce the same results across clients, which is essential for networked physics. It also offers continuous collision detection and the highest body count tested, at 2,000+ bodies at 60 fps.

What are the different types of physics engines?

Physics engines split mainly by dimension (2D versus 3D) and by implementation (pure JavaScript versus WebAssembly). Pure JS engines like Matter.js are simpler but slower. WASM engines like Rapier and Jolt are faster but heavier to set up. Some, like Havok, are tightly bound to one renderer.

Conclusion

The best physics engine for your web app depends on two questions, not a popularity contest: 2D or 3D, and which renderer you are pairing with. Rapier wins on raw performance and CCD; Matter.js wins on simplicity; Cannon-es wins on Three.js tutorial coverage.

The honest reality check: many web projects don't need a physics engine at all, and the one you pick is only as good as how it fits the rest of your stack.

That stack-level fit is exactly what MoreMagpie is built to help with. It shows how a physics engine connects to your renderer and build tools, surfaces the trade-offs, and names the catch, so you carry a clearer brief into your AI builder. MoreMagpie is early and gathering waitlist signups, join the waitlist to get started.