rive-wasm: the Rive runtime, compiled to WebAssembly for the browser

What the runtime is, and where Rive itself fits

rive-wasm is a JavaScript and TypeScript and WebAssembly runtime library for Rive, and the README summarises its job in one sentence. It allows full control over Rive files with a high-level API for hooking up many simple interactions and animations, as well as a low-level API that allows you to drive your own render loop to create multiple artboards, animations and state machines all in one canvas. Rive itself is described as a real-time interactive design and animation tool that helps teams create and run interactive animations anywhere, and the workflow is that designers and developers use a collaborative editor to create motion graphics that respond to different states and user inputs, and the lightweight open-source runtime libraries allow them to load those animations into apps, games and websites. So the split is clear. Rive is the design tool, this repository is the browser runtime that plays the result.

The two APIs, and the multiple artboard case

The high-level and low-level split is the thing to understand before choosing how to integrate. The high-level API is for hooking up many simple interactions and animations, which is the path where the runtime owns the render loop and you tell it what to listen for. The low-level API is for driving your own render loop, and the reason it exists is stated in the same sentence, to create multiple artboards, animations and state machines all in one canvas. A Rive file can contain several artboards, and a page with a character in a hero section and a separate interactive panel needs both on the page at once, which is a single canvas, so you need to decide when each artboard advances and when the frame is drawn. That is a scheduling problem that the low-level API hands to you. The documentation splits the surrounding concepts into separate pages, with Layout, State Machines, Data Binding, Rive Events and Loading Assets each having their own page in the help centre.

The repository is a build of two halves, wasm and js

The top level of the repository shows the build rather than a library package. There is a wasm/ directory holding the WebAssembly side and a js/ directory for the JavaScript and TypeScript side, which is the usual arrangement when a runtime ships a compiled core with a scripting layer on top. There is an assets/ directory and a scripting_lane/ directory, and the root holds a .clang-format file, which tells you the C++ or C core is formatted with clang-format, along with a .gitmodules file for the submodules the build pulls in. Then there are the scripts that are worth noting, generate_size_report.sh, query_wasm_size_change.sh and increment.sh, plus a directory called number and a file called .rive_head. The size scripts are the interesting ones, because the WebAssembly artefact is the part of this runtime that a web page actually downloads, so tracking its size across releases is a real maintenance concern rather than a nicety.

Versioning is dense, and the migration guides are part of the contract

The release history shows how fast the runtime moves. The listed versions are 2.44.0 on 2026-09-30, 2.44.1 on 2026-10-09 and 2.44.2 on 2026-10-10, so two patch versions inside a fortnight. A project on this cadence needs a migration story, and the README has one. If you are using an older version of the runtime and need to learn how to upgrade to the latest, the migration guides in the help centre walk you through major version bumps and breaking changes, and the README links them. There is also a CHANGELOG.md in the repository. The practical advice for an integrator is to pin the version you have tested rather than track the latest, and to read the migration guide for the major bump you are crossing, because a runtime that ships twice a month will have changed its API surface underneath a minor version.

Where the documentation lives, and the split between the repo and the site

The README is mostly pointers, and the pointers are worth mapping because a newcomer will otherwise look in the wrong place. For integration there is the Getting Started with Rive in Web guide and the API documentation on Rive parameters. For concepts there are separate pages for Layout, State Machines, Data Binding, Rive Events and Loading Assets. The examples live in the Rive documentation under Runtimes and demos, and the project also points at the awesome-rive repository for more examples and resources on using Rive at runtime or in other tools. The Rive docs have their own Getting Started introduction, and the Rive homepage is rive.app. So the repository holds the runtime source, the CHANGELOG, the contributing guide and the LICENSE, while everything a developer needs to write code against it is in the hosted documentation, and the versioning story is split across the two, with migration guides on the site and the changelog in the repository.

Browser support, and what the runtime promises about performance

The Supported browsers section is short and slightly qualitative, which is worth reading closely. Rive can be used in all major browsers, and the project says it is constantly working to improve performance with the renderer so that animations playback smoothly for all. That is the only performance claim in the README, and it is a statement of direction rather than a benchmark, so there is no figure to hold the project to. The WebAssembly runtime in particular has a cost, because the artefact is downloaded before anything plays, which is the trade the size-reporting scripts in the repository exist to keep track of. The last push to the repository was on 2026-10-16, the repository is not archived, the licence is MIT, and the primary language is TypeScript.

Contributing and the wider Rive tooling surface

The contributing section points at a CONTRIBUTING.md in the repository root, described as covering how to run the project, the examples and more all locally, and the wording in the README invites contributions directly. The repository also carries a SECURITY-relevant consideration in the form of the .gitmodules file, since a build that pulls submodules pulls code you have to trust. The wider Rive surface has a runtime family, this one for the web, and the awesome-rive repository is the index for the other tools and for further examples, which is the more useful entry point if you are deciding how Rive fits into a stack that is not primarily a web app. The repository also has a .github/ directory with the build workflow that the badge at the top of the README points at, so a build failure in the runtime is visible in the status badge rather than only in the released artefact.

Editorial conclusion

rive-wasm suits a web team that has commissioned interactive motion design in Rive and needs to run it in the browser, and that wants either a quick high-level integration or the control to drive several artboards from its own render loop. It is the wrong choice if you need a Rive runtime outside the browser, since this repository is specifically the JavaScript and WebAssembly runtime, and a poor fit if you want an authoring tool, because Rive itself is a separate design application. Before adopting it, check the migration guides for the major version you are moving from, since the runtime is versioned tightly and the project documents breaking changes per major bump, and note that the wasm/ and js/ directories in the repository hold the two halves of the build, with the size of the wasm artefact tracked by scripts in the root.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rive-app/rive-wasm on GitHub