WASM wheels on PyPI: publish packages for Pyodide browsers

Developers can publish WebAssembly (WASM) wheels to PyPI, enabling distribution of precompiled Python packages for use with Pyodide in browsers. On June 13, 2026, Simon Willison published a step-by-step walkthrough showing how to build a WASM wheel, tag it for the wasm platform, upload it to PyPI, and install it into a Pyodide runtime.

Wheels are the standard binary distribution format for Python packages. A WASM wheel is a wheel whose compiled artifacts target WebAssembly runtimes rather than native operating systems. Packaging extensions or prebuilt C code into a wheel means browser applications using Pyodide do not need to compile sources client side, which reduces setup time and avoids in-browser compilation costs for users.

How publishing a WASM wheel works

A WASM wheel is created the same way as other wheels, but the build output contains WebAssembly artifacts and the wheel metadata declares a wasm platform tag. The core steps demonstrated in the walkthrough are: building the extension or native module for a wasm32 target, placing the.wasm artifact and any supporting files into the wheel archive, ensuring the wheel metadata uses the correct platform tag for wasm, and uploading the final wheel file to PyPI via the usual upload mechanisms.

Once on PyPI, the wheel can be fetched by Pyodide or other browser-side package loaders that understand wheels targeted at WebAssembly. In a browser environment running Pyodide, fetching and installing a WASM wheel provides prebuilt modules ready to import without additional compilation. This is especially valuable for libraries that wrap C libraries or perform heavy numerical work where a source install would otherwise trigger a compile step that cannot run in the browser.

Limitations and compatibility

Not every Python package is a good fit for a WASM wheel. Packages that depend on system-level services, native OS APIs, or external processes will not run in a sandboxed WebAssembly environment. Developers must target WebAssembly-compatible subsets of their code and ensure any native dependencies can be compiled to wasm32 and expose interfaces usable from CPython compiled for WebAssembly.

Tooling is evolving. Build backends and extension toolchains need configuration to produce wasm artifacts and the correct wheel metadata. Testing remains important: a successful build does not guarantee runtime compatibility in all browser contexts. The Pyodide runtime has its own loader and expectations, so packages published to PyPI should be validated by installing them into a Pyodide build and running typical import and runtime scenarios.

The ecosystem considerations include PyPI indexing and installer behavior. A wheel that declares a wasm platform tag will generally be ignored by native Python installers on desktop systems, which prevents accidental installs on incompatible platforms. That separation lets authors publish separate wheels for native platforms and for wasm, keeping distribution flows consistent while targeting the browser.

Why it matters

Publishing WASM wheels to PyPI lowers the barrier for distributing prebuilt Python extensions to browser-based Python environments. Library authors can target Pyodide users without forcing client-side compilation, broadening the set of packages that can run in the browser. For web developers and data scientists using Pyodide, more prebuilt wheels means faster load times and fewer compatibility workarounds when bringing Python libraries into the browser.