Pyodide 314.0, the WebAssembly build of CPython, lets any author publish a browser ready distribution to the standard Python package index, ending years of manual curation by core maintainers.
For years, getting a Python package into the browser required a special relationship with a small group of Pyodide maintainers, who reviewed, built, and hosted each browser-ready distribution by hand. As of Pyodide 314.0, that gate is gone. A package author can now publish a WebAssembly wheel to the standard Python Package Index (PyPI) and install it at runtime in the browser with micropip, ending the need for a special install path.
The change rests on two pieces that landed within the last seven weeks. On April 21, 2026, PyPI maintainer Miro Hrončok merged warehouse pull request #19804, adding the new PyEmscripten platform tags to the index's accepted list. Pyodide 314.0, released this week and walked through in detail by Simon Willison, pairs that PyPI-side unlock with a runtime that recognizes the tags and resolves them through micropip. Together, they turn browser-targeted Python into a normal publishing target, sitting alongside Linux, macOS, and Windows.
The PyEmscripten platform tags defined in PEP 783 are what make the new workflow possible. With them, an author can target the browser the same way they target any other platform, and the build toolchain is already in place: cibuildwheel 4.0 supports the 2025 and 2026 PyEmscripten ABIs out of the box. The 2026 ABI, used by Pyodide 314.0, currently needs a pyodide-prerelease flag in cibuildwheel until version 4.1 ships. Once that lands, building a wheel for the browser should look the same to a maintainer as building for any other platform.
The workflow is already live and reproducible. Willison published a worked example, luau-wasm, a 276-kilobyte wheel that ships a C++-compiled Luau interpreter built with cibuildwheel on GitHub Actions. The result installs in the Pyodide REPL with a single await micropip.install('luau-wasm') call. Off-the-shelf packages are following: a BigQuery scan of PyPI's public dataset, reproduced in Willison's post, already counts 28 packages publishing pyemscripten_202*_wasm32 wheels, including pydantic_core, onnx, tcod, typst, geoarrow-rust-core, and several arro3 packages. In the public Pyodide console, await micropip.install('pydantic_core') pulls a pydantic_core-2.47.0-cp314-cp314-pyemscripten_2026_0_wasm32.whl straight from PyPI.
Pyodide 314.0 also rebrands. The project moves from 0.29.x versioning to 314.x, tying each release to the upstream CPython major version (3.14 = 314) and committing to an annual cadence aligned with CPython. The release ships Python 3.14.2 and Emscripten 5.0.3. The standard library is reshuffled. ssl, sqlite3, and lzma are re-vendored; pydecimal and the test packages are gone; fullstdlib is deprecated; and OpenSSL is dropped, so the ssl module now uses a custom implementation without real TLS, while hashlib loses some OpenSSL-backed algorithms. For anyone running Pyodide in a browser and touching ssl or hashlib, that is a real breaking change to plan around.
Two more shifts matter for migration. The runtime file pyodide.asm.js is renamed pyodide.asm.mjs, which breaks static imports and a few bundler configurations. And experimental Node.js socket support, gated behind useNodeSockFS() and a --experimental-wasm-stack-switching flag on Node 24 or earlier, lets packages like pymysql, pg8000, and redis-py talk to a real socket from the Node side. It is a flagged experiment, not a stable path.
What to watch next: whether the cibuildwheel 4.1 release pulls the pyodide-prerelease flag into the default build matrix, whether PEP 783 evolves a name that reads better than pyemscripten_2026_0_wasm32 for a typical PyPI searcher, and whether the dropped OpenSSL support in ssl and hashlib forces browser-side projects that need real TLS to ship their own bindings. The bottleneck is gone; the migration work is just starting.