Skip to main content
Guides

Which Python Packages Work in an Online Compiler? 24 Tested

By Mithun··8 min read
Quick Answer

Most of the popular data-science and utility packages work. I tested 24 packages on the exact runtime our online Python compiler uses — Pyodide 0.28.0 (CPython 3.13) — and 20 installed and imported cleanly: NumPy, pandas, SciPy, scikit-learn, Matplotlib, SymPy, NetworkX, Pillow, OpenCV, cryptography, lxml, requests, BeautifulSoup, PyYAML, Pydantic, Jinja2, Click, Rich, regex and python-dateutil. What doesn't work: packages whose C extensions aren't built for WebAssembly (PyTorch, TensorFlow, psycopg2Can't find a pure Python 3 wheel), and live network calls (requests installs but the browser sandbox has no sockets). Full tested table below.

"Can I use NumPy / pandas / scikit-learn in an online Python compiler?" is one of the most common questions about browser-based Python, and the honest answer is: it depends on the package. A browser compiler runs Pyodide — real CPython compiled to WebAssembly — so it ships pre-built WASM wheels for a lot of the scientific stack, installs many pure-Python packages on the fly, and simply can't run others. Rather than guess, I tested 24 packages against the same Pyodide build our compiler uses and recorded exactly what installs, what fails, and why.

How a browser compiler loads packages

Our online Python compiler runs Pyodide — a full CPython (3.13 on the default build, Pyodide 0.28.0) compiled to WebAssembly that runs entirely in your browser tab. There's no server and no pip. When you hit Run, it scans your imports and loads packages two ways: Pyodide's own pre-built WASM wheels for the big scientific libraries (NumPy, pandas, SciPy…), and `micropip` to fetch pure-Python wheels for everything else. A package works if a WebAssembly-compatible wheel exists; it fails if the library needs a C extension no one has compiled for WASM.

This is a real, standards-based CPython — not a limited sandbox or a transpiler. The only hard limits are WebAssembly ones: no raw network sockets, no threads by default, and C extensions must be compiled for WASM.

The results: 24 packages tested (Pyodide 0.28.0 / Python 3.13)

Each package was installed and then imported on the Pyodide runtime the compiler uses. "Load" is the first-time install/import time; note that shared dependencies mean some packages are near-instant once another package has already pulled them in (Pillow arrives with Matplotlib, python-dateutil with pandas), and in the browser you also pay Pyodide's one-time startup (~2–4s).

PackageimportWorks?Load
numpynumpyYes1.3s
pandaspandasYes4.2s
scipyscipyYes5.5s
scikit-learnsklearnYes6.5s
matplotlibmatplotlibYes3.4s
sympysympyYes7.4s
networkxnetworkxYes1.7s
pillowPILYeswith matplotlib
opencv-pythoncv2Yes3.9s
cryptographycryptographyYes0.5s
lxmllxmlYes1.0s
requestsrequestsInstalls (no live network)1.0s
beautifulsoup4bs4Yes0.6s
pyyamlyamlYes0.6s
pydanticpydanticYes0.6s
jinja2jinja2Yes0.4s
clickclickYes1.0s
richrichYes0.7s
python-dateutildateutilYeswith pandas
regexregexYes0.5s
fastapifastapiNo — dependency conflict
psycopg2psycopg2No — needs native libpq
torch (PyTorch)torchNo — no WASM wheel
tensorflowtensorflowNo — no WASM wheel

20 of 24 worked. The whole common data/analysis stack is there, plus the everyday utilities. The four failures split into three distinct reasons — worth understanding, because they tell you what will and won't work for packages I didn't test.

What works: the data-science stack and common utilities

Everything you'd reach for in a notebook works: NumPy, pandas, SciPy, scikit-learn, Matplotlib, SymPy, NetworkX, Pillow and even OpenCV — these ship as Pyodide's own WebAssembly wheels (you'll see them download as ...-pyodide_2025_0_wasm32.whl), so they're fast and reliable. On the utility side, requests, BeautifulSoup, lxml, PyYAML, Pydantic, Jinja2, Click, Rich, regex, python-dateutil and cryptography all install and import cleanly via micropip. If a package is pure-Python or is in Pyodide's built distribution, it just works.

What doesn't: native extensions and heavy ML

Packages that rely on a C/C++ extension nobody has compiled for WebAssembly can't be installed. In the test that was psycopg2 (needs the native libpq Postgres client), PyTorch and TensorFlow — micropip refuses them with a clear message:

ValueError: Can't find a pure Python 3 wheel for 'psycopg2'.
ValueError: Can't find a pure Python 3 wheel for 'torch'.
ValueError: Can't find a pure Python 3 wheel for 'tensorflow'.
Real micropip output for unsupported packages

That message is the tell: "no pure Python 3 wheel" means the library needs compiled code that isn't available for WASM. Heavy ML frameworks (PyTorch, TensorFlow), database drivers (psycopg2, mysqlclient) and anything wrapping a system library generally fall here. The rule of thumb: if pip install normally builds C code on your machine, it probably won't run in the browser.

The gotcha: a dependency conflict, not "unsupported"

FastAPI is pure Python and *should* work — but it failed, and not for the reason you'd expect:

ValueError: Requested 'typing-extensions>=4.15.0', but
typing-extensions==4.14.0 is already installed
FastAPI install — real error

FastAPI pinned a newer typing-extensions than the version Pyodide had already loaded, so the install aborted. This is a common and easily-misread failure: the package isn't unsupported, a transitive dependency just clashed with what's already in the environment. The fix is usually to pin a compatible version yourself (e.g. install an older FastAPI, or the specific typing-extensions first) — worth knowing before you conclude a pure-Python package "doesn't work in the browser."

The network limitation (read this before using requests)

requests installs and imports fine — but a browser tab has no raw network sockets, so requests.get(...), urllib and the socket module can't make real connections. This is a WebAssembly/browser sandbox constraint, not a bug in the compiler, and it applies to every browser-based Python. For HTTP inside Pyodide you use its own fetch bridge instead:

from pyodide.http import pyfetch
resp = await pyfetch("https://example.com/data.json")
data = await resp.json()
Fetching a URL the way that works in the browser

So: use requests/BeautifulSoup to parse HTML or build requests, but fetch the bytes with pyodide.http.pyfetch (or JavaScript fetch). Anything that needs a raw socket — database drivers, most network clients — won't connect from the browser.

How to install packages in the compiler

You usually don't have to do anything: just import numpy and hit Run — the compiler detects the import and installs the package automatically. For a specific version or a package whose import name differs from its PyPI name, add a requirements.txt (e.g. pydantic==2.10.6) and it's installed via micropip before your code runs. No pip, no terminal, nothing to set up locally.

Try it

Run any of these packages yourself in the browser — no install, no signup. Our online Python compiler loads the package on Run and executes real CPython 3.13 (with 3.12 and 3.11 available too). Paste a NumPy or pandas snippet and watch it install and run in the tab.

Run NumPy, pandas or OpenCV in your browser

Our free online Python compiler installs the package on Run and executes real CPython 3.13 — no install, no signup.

Open the Online Python Compiler

Free tools mentioned here

Related guides

Frequently asked questions

Can I use NumPy and pandas in an online Python compiler?

Yes. On the Pyodide runtime our compiler uses (0.28.0 / CPython 3.13), NumPy, pandas, SciPy, scikit-learn, Matplotlib and the rest of the scientific stack install and import cleanly — they ship as pre-built WebAssembly wheels. Just import them and click Run; the compiler loads the package automatically. In testing, NumPy loaded in ~1.3s and pandas in ~4.2s on first use.

Why can’t I install PyTorch or TensorFlow in a browser Python compiler?

Because they rely on large C/C++/CUDA extensions that haven't been compiled to WebAssembly, so no WASM-compatible wheel exists. micropip reports 'Can't find a pure Python 3 wheel for torch/tensorflow'. The same applies to database drivers like psycopg2 (native libpq) and most packages that wrap a system library. Pure-Python packages and Pyodide's bundled scientific stack do work.

Does requests work in an online Python compiler?

requests installs and imports, but it can't make real network calls — a browser tab has no raw sockets, which is a WebAssembly sandbox limitation, not a compiler bug. Use pyodide.http.pyfetch (or JavaScript fetch) for HTTP instead. You can still use requests/BeautifulSoup to parse or build requests; you just fetch the bytes with pyfetch.

A pure-Python package failed to install — why?

Often it's a dependency version conflict, not a lack of support. In testing, FastAPI failed with 'Requested typing-extensions>=4.15.0, but typing-extensions==4.14.0 is already installed' — a transitive pin clashed with a version Pyodide had already loaded. Pin a compatible version (install an older release, or the specific dependency first) rather than assuming the package doesn't work in the browser.

How do I install a specific package version in the compiler?

Add a requirements.txt with a pinned line (e.g. numpy==2.2.5 or pydantic==2.10.6). The compiler installs it with micropip before running your code. For most packages you don't even need this — just import the package and it's installed automatically on Run.

Keep reading