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, psycopg2 — Can'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).
| Package | import | Works? | Load |
|---|---|---|---|
| numpy | numpy | Yes | 1.3s |
| pandas | pandas | Yes | 4.2s |
| scipy | scipy | Yes | 5.5s |
| scikit-learn | sklearn | Yes | 6.5s |
| matplotlib | matplotlib | Yes | 3.4s |
| sympy | sympy | Yes | 7.4s |
| networkx | networkx | Yes | 1.7s |
| pillow | PIL | Yes | with matplotlib |
| opencv-python | cv2 | Yes | 3.9s |
| cryptography | cryptography | Yes | 0.5s |
| lxml | lxml | Yes | 1.0s |
| requests | requests | Installs (no live network) | 1.0s |
| beautifulsoup4 | bs4 | Yes | 0.6s |
| pyyaml | yaml | Yes | 0.6s |
| pydantic | pydantic | Yes | 0.6s |
| jinja2 | jinja2 | Yes | 0.4s |
| click | click | Yes | 1.0s |
| rich | rich | Yes | 0.7s |
| python-dateutil | dateutil | Yes | with pandas |
| regex | regex | Yes | 0.5s |
| fastapi | fastapi | No — dependency conflict | — |
| psycopg2 | psycopg2 | No — needs native libpq | — |
| torch (PyTorch) | torch | No — no WASM wheel | — |
| tensorflow | tensorflow | No — 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'.
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', buttyping-extensions==4.14.0 is already installed
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 pyfetchresp = await pyfetch("https://example.com/data.json")data = await resp.json()
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 CompilerFree 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.