Scientists, students, and engineers use Jupyter notebooks to explore ideas interactively: write a small piece of code, execute it, inspect the result, and continue from there. Traditionally, every such notebook requires a Python process running on a server or on the user's machine.

JupyterLite changes this model. Its kernels run locally in the Web browser through WebAssembly, so a static website can provide a complete computational environment without allocating a server to every user. This makes notebooks easier and cheaper to share at scale, whether they are used for documentation, education, or interactive demonstrations.

There has, however, been an important piece missing from the browser-based scientific Python ecosystem: Numba.

Today, we are excited to share the first working version of the Numba JIT compiler running entirely in the browser with JupyterLite and emscripten-forge!

Numba in action in JupyterLite, showing a 249× speedup over standard Python.

In this example, Numba delivers a roughly 250× speedup in WebAssembly, compared with about 90× natively. The larger relative gain makes Numba especially compelling in the browser, where bypassing Python interpreter overhead can have an even greater impact.

This means that a Python function can be transformed into Numba's Intermediate Representation (IR), typed, lowered to LLVM IR, compiled into WebAssembly, dynamically linked, and executed—all without a remote Python server.

Try it here: Numba and its ecosystem in JupyterLite.

A long-standing request​

Support for Numba in WebAssembly has been discussed for many years. The request appeared in the Numba project as early as 2018 in numba/numba#3284, while the Pyodide community tracked the packaging challenge in pyodide/pyodide-recipes#192.

The difficulty was not simply that Numba had never been packaged for WebAssembly. Numba is a compiler, and its execution model depends on llvmlite and LLVM. On a native platform, generated machine code can be placed into executable memory and called immediately. The browser deliberately does not allow applications to create or modify executable memory in this way.

Consequently, bringing Numba to the browser required more than adapting a build system or fixing a few platform checks. We needed a WebAssembly-aware execution engine for llvmlite, a way to invoke the LLVM linker inside the running browser process, and support for dynamically loading the generated code into the persistent Python runtime.

Fortunately, this was a problem we had encountered before.

From interactive C++ to llvmlite​

Our earlier work on Xeus-Cpp in JupyterLite brought the Clang-Repl C++ interpreter to the browser. Clang-Repl cannot use LLVM's conventional JIT machinery under WebAssembly either, so we introduced a WebAssembly execution model with a different pipeline:

1. Compile the generated LLVM IR into a WebAssembly object file.
2. Link that object with wasm-ld into a WebAssembly side module—the WebAssembly equivalent of a dynamically loaded shared library.
3. Dynamically load the side module into the running application.
4. Resolve its symbols and call the compiled function.

Each new input incrementally extends the running program. The newly loaded side module shares memory with the main application, and its exported symbols can be used by modules loaded later.

This work is now the foundation of Xeus-Cpp in the browser. It is also the subject of our FOSDEM 2026 talk on interactive C++ workflows.

The central realization behind this project was that a similar architecture could be applied to llvmlite.

We implemented a WebAssembly execution engine that takes LLVM modules produced through llvmlite, emits WebAssembly objects, invokes LLVM's linker, LLD, through its in-process re-entrant driver, and loads each result as an Emscripten side module. Using LLD in process is essential: spawning a wasm-ld subprocess is not an option inside the browser.

The modules are loaded globally and kept alive, allowing runtime libraries, compiler-generated helpers, and user functions to resolve one another. This gives llvmlite the incremental execution behavior required by Numba while respecting the browser's security model.

Before moving further up the stack, we used this engine directly to compile, optimize, inspect, and execute LLVM IR. We also enabled in-process Graphviz rendering, making it possible to display control-flow graphs without launching the dot executable as a subprocess.

You can explore this lower-level pipeline here: llvmlite and Graphviz in JupyterLite.

Building LLVM IR and rendering its control-flow graph entirely in the browser.

Walking up the stack to Numba​

Numba begins at a much friendlier level. A user writes an ordinary Python function and applies @jit or @njit:

from numba import njit

@njit
def add(a, b):
    return a + b

add(1.0, 2.5)

Behind this small example lies a complete compiler pipeline. Numba reads the Python bytecode and constructs its own intermediate representation. It infers concrete types for the arguments and intermediate values, performs compiler transformations, and lowers the typed program to LLVM IR through llvmlite.

On a native machine, llvmlite would hand the result to LLVM's JIT execution engine. In JupyterLite, it instead hands the module to the new WebAssembly engine. The module is compiled, linked as a side module, loaded into the running Xeus-Python kernel, and exposed through the WebAssembly function table so that Numba can call it.

A single user function can involve several modules. Numba may first load runtime support such as the Numba Runtime (NRT), then compiler-generated helpers, and finally the module containing the user function and its CPython-callable wrapper. These modules must be loaded in the correct order so that later code can resolve symbols provided by earlier modules.

We also added persistent object caching through @njit(cache=True). When a cache-enabled function is used again in a later browser session, Numba restores its cached compilation data from JupyterLite's persistent filesystem. llvmlite reuses the corresponding WebAssembly object, while relinking and loading a fresh side module into the new kernel process.

The result is genuine Numba compilation and execution in the browser—not an interpreter that imitates Numba, and not a remote service hidden behind the notebook.

Packaging Numba on emscripten-forge​

Once we got Numba to work in the browser, the key to adoption is being able to distribute the software. This is where emscripten-forge comes in. Emscripten-forge is a software distribution for WebAssembly in the browser. It is built upon the conda/mamba stack and conda-forge, and provides a complete package management solution for the Web browser, and a broad collection of packages, including the Python scientific stack (NumPy, SciPy, LLVM, Clang, LLD), the R stack, but also native command-line applications and complete toolchains.

Numba is now available in emscripten-forge, and can now be easily used in JupyterLite deployments!

Dynamically installing the WebAssembly build of Numba with Mamba in the JupyterLite terminal.

Unlocking the ecosystem above Numba​

Getting a scalar addition to compile is an important milestone, but the broader motivation is the ecosystem that becomes possible once Numba is available.

Our demonstration starts with recognizable Numba examples and numerical array kernels. It then walks upward through packages that use Numba directly or through their own compilation backends:

• PyTensor can compile symbolic numerical graphs using its Numba linker.
• PyMC, built on PyTensor, brings familiar probabilistic models into the same browser environment.
• interpolation.py provides Numba-accelerated interpolation routines used in numerical economics.
• Dolo.py builds on this stack to provide JIT-aware numerical routines for economists (stochastic processes, decision rules), along with optimized solution methods for dynamic programming problems.

In other words, enabling one compiler unlocks considerably more than one package. It opens a path for statistics, probability, economics, and scientific computing libraries that previously could not bring their full execution model to JupyterLite.

The Numba ecosystem running through Xeus-Python in JupyterLite.

Try the complete progression here: Numba, PyTensor, PyMC, Interpolation.py, and Dolo.py in the browser.

What comes next?​

The current work establishes the end-to-end architecture, but there is more to do. We want to move the changes upstream in focused contributions, expand test coverage across the Numba and llvmlite suites, improve performance and persistent caching, and validate more packages from the wider Numba ecosystem.

WebAssembly target features such as SIMD also provide an exciting direction for numerical kernels. At the ecosystem level, projects that rely on Numba can now be evaluated for browser support instead of excluding WebAssembly from the outset.

Most importantly, this work demonstrates that a sophisticated compiler stack does not have to stop at the boundary of the Web browser. With LLVM, LLD, llvmlite, and Numba available through emscripten-forge, JupyterLite can grow from a lightweight Python environment into a platform for serious compiled scientific computing.

We are excited to see what the community builds on top of it!

About the author​

Anutosh Bhat is a scientific software developer at QuantStack. He is an LLVM maintainer and a co-author of the Xeus-Cpp Jupyter kernel for C++. Anutosh led the WebAssembly integration for llvmlite and Numba.

Acknowledgements​

This work was developed at QuantStack and builds on contributions across LLVM, Clang-Repl, Emscripten, llvmlite, Numba, Xeus-Python, JupyterLite, Graphviz, and emscripten-forge.

We are grateful to the maintainers and contributors of these projects, and particularly to the Numba community for the discussion around upstreaming this work.

Fig above: Computation of a blackhole approach trajectory using EinsteinPy. This trajectory was computed fully in-browser relying on community Python code, demonstrating the power of WebAssembly for easily exploring advanced concepts or calculations.

TL;DR: Browser-native scientific computing means a full compute environment — Python, R, C++, or any language that compiles to WebAssembly — running inside your browser. It arrives as simple static files: no backend, no installation, no setup required. An entire environment can be handed over as a URL, and is highly accessible, secure, and reproducible because WebAssembly, a standardised web technology, was made for safe sharing across devices and time. Since compute happens on the user's own machine, serving one user or a hundred thousand costs about the same, opening up new possibilities — giving nationwide access to code for students, public data portals with embedded compute environments, runnable documentation, and executable blog posts or papers. The technology is used in production and available today.

Introduction​

There is a moment almost everyone who has touched code has lived through. Instructions arrive to run an analysis, a tutorial, or a classroom exercise. Following them consumes the next two hours in installing, configuring, and debugging an environment that works perfectly on someone else's machine — all while npm install, pip install, or conda install quietly pulls in hundreds of random packages that now have reach into local files and private data.

In this post we'll talk about a new paradigm that avoids this situation: sharing a complete compute environment — Python, R, C++, and more — entirely inside a web browser, with no installation, no server, no configuration, and strict isolation. In this paradigm you click a link and you have your project set and ready to execute. That's it.

This article explains this new paradigm, how it works, where it fits, and where it doesn't.

The incumbent model: OS-native compute​

Today, most scientific compute software, even when written in interpreted languages like Python, boils down to using compiled code. More specifically it is compiled from source code directly into machine instructions for a specific CPU and operating system (OS). While the CPU executes those instructions, memory management, I/O, network access, threading, process lifetime, and more all pass through the operating system. And OSs give code broad power, direct access to the file system, hardware, and network, and generous freedom for the compiler to use liberal memory layouts and apply aggressive optimisations. Their design, from a pre-internet era, largely assumes that responsible users install trusted software, which justifies few restrictions on optimisations or access to machine resources — for the sake of maximum performance and capability. This model — call it OS-native — has powered scientific applications for decades.

Unfortunately, the very properties that make OS-native so fast and powerful also make it inherently unsuited to safe, robust, and easy sharing. Tight coupling to the host machine makes OS-native deeply integrated and frictionless, but ties every program to the specific system it was built on — a different library version, path, or configuration on another machine and pieces break. Flexible memory layouts and liberal control flow permit aggressive performance optimisations, but also open the door to malicious exploits. And the common default of granting unknown, untrusted code full access to user documents, the local network, and other resources may be a convenience on a single trusted machine, but becomes a liability when sharing code in a wider setting. Symptoms of all this include the reproducibility crisis and the recent proliferation of supply chain attacks.

The browser, on the other hand, was designed from the start for safe, massive sharing, and for the distributed execution of untrusted code across devices and time (see e.g. Security Architecture of the Chromium Browser). It imposes safety and compatibility restrictions that, in massive return, yield the power of the internet: publish once, reach anyone on any device without prior installation, heavy centralised infrastructure or trust.

Scientific computing has approached this idea repeatedly. Attempts running compute on the user's machine inside the browser include Java applets, Flash, Google's Native Client, asm.js and more — reaching large audiences through projects like PhET and GeoGebra. But most delivered only narrow slices: click-and-slide simulations, canned demos, or small language subsets. And many of them were non-standardized bolt-on technologies, causing the usual compatibility issues, rather than something integrated in the browser from the ground up. What has never quite arrived is the complete picture — arbitrary user code, in any language, running on the user's own machine, standardized in any browser without a plugin.

Another popular approach, classic Project Jupyter (as opposed to JupyterLite, which we will talk about later), delivers arbitrary code execution in any language, but leaves the compute off the user's machine on a remote server. Users can access a preconfigured compute environment from any device, with no local install to manage. The remote compute environment is what the kernel provider preinstalled; the setup burden hasn't gone away, it has just shifted to whoever runs the service. Compute still runs on someone else's OS-native machine and the model therefore can't deliver the full power of web-like sharing: one remote VM or container per active user, including capacity for peaks, means heavy load at scale on whoever runs the service. Necessary access controls for such remote resources mean no free sharing. The OS-native reproducibility and dependency-fragility problems from earlier still exist, just hidden behind a server. And user data has to leave the user's machine to be operated on. Cloud services like Google Colab or Replit shift the operational burden to a third party — lowering costs at scale — but bring their own trade-offs around data locality, customisation, integration with internal systems, and cost.

What has arrived is that complete picture — the piece neither of these approaches quite reached: arbitrary user code, in any language, running on the user's own machine, standardized in any browser without a plugin. Sharing and using entire compute environments becomes as easy as opening a webpage: the environment is a static file that any web server can deliver, and serving one user or a hundred thousand costs about the same thanks to safe, distributed execution.

The very properties that make OS-native software powerful also make it inherently unsuited to safe, robust, and easy sharing.

The new paradigm: browser-native compute​

Browser-native adds a layer between source and OS-native instructions: WebAssembly. The source is first compiled to a .wasm binary, delivered to the browser as a static file, and compiled by the browser's WebAssembly engine into native machine code (V8 in Chrome, SpiderMonkey in Firefox, JavaScriptCore in Safari). The compiled native code runs directly on the CPU, the way any OS-native program does except within the browser process and potentially calling a light WASM runtime at boundaries (imports, host calls, memory growth) in the same way an OS handles syscalls in an OS-native model. Safety comes from validation against the spec before execution, from boundary checks that are compiled into the emitted native code, and from the browser's own process sandbox surrounding all that.

Such intermediate layers, portable bytecodes and in-browser VMs aren't new. What is new is WASM's low level, lightweight, sandboxed and highly standardized approach contrasting strongly with VMs focusing on OS-native or featureful language execution (JVM, JavaScript, ...). It also contrasts with Java applets, Flash, and Native Client that are browser-native in intent, but vendor-specific plugins often built for narrow use cases. WebAssembly itself was designed based on experience with using JavaScript and its engine directly as intermediate layer which hit limitations on parse time for large binaries, file size, cross-browser standardization, the unpredictability of performance and more. Co-designed by all major browser vendors, WASM replaced this workaround with an intermediate layer that is appropriately designed for the use case of performant, safe in-browser code execution — compact binary, structured control flow, linear memory. This design means fast and easy compilation to safe native machine code that runs with minimal runtime overhead, and execution close in shape to what an OS-native compiler would have produced from the same source. For a longer primer, Jakob Meier's Wasm in the Wild series is a good starting point.

Execution through the browser thus enables what operating systems were not built for: running arbitrary code from any origin, safely and identically, on any device. Two consequences follow for scientific compute. Safety: a .wasm can touch nothing beyond what the surrounding page hands it, so running code delivered by a stranger is genuinely safe. Reproducibility: it cannot depend on host state (environment variables, system libraries, ambient configuration) that varies from device to device, and every browser runs the same spec, so the same URL behaves the same on a laptop, a Chromebook, or a phone. Together these enable sharing and instant accessibility at scale.

On top of this foundation, over the last several years the scientific computing community has compiled a large fraction of the scientific software stack to WebAssembly. The effort was pioneered by Pyodide, which started at Mozilla in 2018 by porting CPython and a core set of scientific packages to run in the browser. Since then it has grown to cover the wider Python ecosystem (NumPy, SciPy, pandas, scikit-learn, matplotlib, and hundreds more), the R interpreter, and many C, C++, and Fortran libraries that sit underneath them — today all available for in-browser execution.

Practically, the browser-native paradigm means provisioning a compute environment for 40 users or 40,000 is essentially the same (not considering integrations, persistent storage or related permissions as encountered in more ambitious use cases). Operation and infrastructure costs drop, large-scale use becomes feasible. From the user perspective, access is reduced to a single click — no installation, no waiting for a container to spin up. Any device with a modern browser is a viable target, including mobile (although you may hit memory limits, particularly on iPhone), tablets, and locked-down corporate laptops, because everything the environment needs is safely delivered through the browser.

That this works can be seen in large production deployments leveraging this paradigm to serve hundreds of thousands of users today. Capytale, run by the French Ministry of Education, serves hundreds of thousands of students and tens of thousands of teachers on a very small server footprint, because the servers only deliver static assets while the compute happens in students' browsers. try.jupyter.org offers a public REPL powered by JupyterLite that is used regularly by learners as access patterns show.

Serving one user or a hundred thousand costs about the same — because the compute happens on the user's own machine.

Capabilities and limits​

Two natural questions come up: what can a browser-native environment actually do, and how fast does it run. Both benefit from separating what is structural about the paradigm — and will not change — from what is a moving engineering frontier, likely to look different in a year.

Start with what a WebAssembly module can access. In the browser, it can affect the outside world only through capabilities the host provides. In practice that means the standard capabilities any website has: network access through fetch (subject to same-origin rules), persistent storage through the Origin Private File System (a per-site sandbox the browser manages, not general filesystem access), and hardware — camera, microphone, USB, GPU — as well as local network through the same permission-gated APIs any web page uses. There is no direct filesystem access, no arbitrary sockets, no shelling out to system tools. This is structural; it is exactly what makes the sandbox trustworthy, and enables sharing in the first place. It is not going away.

Performance in practice. Once loaded, WebAssembly runs as real native machine code — no interpreter loop between your code and the CPU for calculations that don't involve boundaries. In V8, for example, a baseline compiler (Liftoff) emits machine code in a single pass for fast startup, and a background optimising compiler (TurboFan) patches in higher-quality code for functions that stay hot. At the boundaries, every memory access may add a cheap bounds check if it can't be optimized away (predictable loops) or handled by hardware (on 64 bit machines), and operations like memory growth pass through the WASM engine. These checks are cheap on modern engines but not zero. Beyond that, a small number of compiler optimisations are permanently excluded because they would be unsafe on untrusted code from the open web (structural); others are simply not yet in the WebAssembly specification or not leveraged by WASM-specific build recipes or code paths but can be expected to arrive gradually; and finally some functions hit hard barriers, for example on multithreading that can greatly affect them.

Considering this, many functions from compiled numerical libraries (NumPy, SciPy, matplotlib, and the C/Fortran underneath) run near-native, with benchmarks on numerical kernels showing on average mid 2-digit percent overheads versus native but sometimes up to 2-2.5x (Jangda et al.'s Not So Fast quantified the gap on SPEC CPU and traced most of it to bounds-checking and register pressure — a reasonable ceiling for any WASM stack), and occasionally even matching or exceeding native when the native build uses a less-optimised backend. For interactive small-data analysis, visualisation, and exploratory work this overhead is often imperceptible and less than the overhead of using shared remote resources. However, occasionally a function hits a hard restriction, is not yet optimized well for the WASM context, or hits real structural limitations such as multithreading (see below). Such situations don't happen randomly, though — they can be identified in advance and potentially remediated. Pure Python code — loops, string manipulation, interpreter-level logic — pays a compounded overhead because CPython itself is running inside WebAssembly; the gap is typically a few-fold (2 - 5x) but has been narrowing (e.g. from Pyodide's own benchmarks).

The structural limits are important to keep in mind: sandboxed execution with no direct syscalls, hardware or OS access, and the excluded-for-safety subset of aggressive compiler optimisations. Other limits are engineering frontiers being actively pushed and are likely to evolve:

• Memory: the 4 GB linear-memory ceiling per module comes from WebAssembly's 32-bit address space; the Memory64 WASM spec proposal removes it and is landing in engines and toolchains. Meaningfully larger single-module datasets are close. Phones may impose tighter runtime limits, whereas modern Android phones can manage a full JupyterLite + scientific Python environment quite well, iPhones seem to be more restrictive on memory (~1 GB), which is a blocker for full mobile access.
• Threading: shared-memory multi-threading requires COOP/COEP cross-origin isolation headers (a safety mechanism), which not every deployment can set — but even with those in place, making scientific runtimes actually use threads efficiently in the browser remains a genuinely hard engineering problem. Browser-native compute is effectively single-threaded in practice today, and progress here is real but incremental.
• GPU: WebGPU provides browser-standard access to GPU compute and is now available across major browsers — but integrating it into the scientific WASM stack, so that NumPy-style code or ML frameworks transparently accelerate on the GPU, is a genuinely hard engineering problem still in its early stages. Direct low-level GPU access from WASM works today; drop-in GPU-accelerated scientific libraries at desktop maturity do not.
• Package coverage: while many packages are available, and pure python or noarch conda packages often run out of the box, there is still a large amount of packages to port so that they are available at all in WASM. And even then, subsets of their functionality may not be immediately available due to the other limitations mentioned above. Right now every use case requires evaluation but the ecosystem has reached critical mass where porting is no longer a daunting task in many cases. Emscripten-Forge alone is at several hundred libraries and expanding.

For a scientist or teacher deciding whether this fits their work: browser-native compute is already the right default for many interactive, exploratory, and educational workloads on small-to-medium datasets. It is not a replacement for OS-native compute if you need full freedom and all the power your machine can provide. Equally it is not a replacement for HPC clusters, GPU training servers, or large-scale distributed data processing — those workloads belong on remote infrastructure by nature. But browser-native environments can offer two complementary roles: acting as an access console to powerful remote machines (through lightweight protocols like Spark Connect), and as an accessible local environment for exploring or visualising predigested data returned from those backends — heavy computation remote, interactive analysis in the browser.

The open source landscape for browser-native compute​

Several complementary open source projects make browser-native scientific computing possible — the tour below is representative, not exhaustive: additional xeus kernels and various runtime shims sit alongside these but are outside our scope here. A quick disclosure before the tour: Notebook.link (the product this post is written for) is built on JupyterLite, Emscripten-Forge, and mambajs, all open source under permissive licenses and originated or co-maintained by QuantStack alongside a broader community. What follows aims to map the wider landscape fairly, including projects QuantStack does not contribute to.

JupyterLite is a version of JupyterLab that runs kernels entirely in the browser. It provides the familiar notebook interface — cells, outputs, markdown, visualisations — without any server process. It was created at QuantStack and is now maintained by a community of contributors from across the Jupyter ecosystem.

Pyodide is a port of CPython to WebAssembly, along with a foreign function interface that lets Python call JavaScript and vice versa. It ships a curated set of scientific Python packages and provides an in-browser package installer (micropip) that can pull Python wheels directly from PyPI, including compiled Emscripten wheels now that PyPI accepts the WebAssembly platform tag (PEP 738) — so from the user's perspective it feels much like pip install. Pyodide executes Python code inside the browser in many JupyterLite deployments.

WebR is the R counterpart to Pyodide — a port of the R interpreter to WebAssembly, developed by the r-wasm project (sponsored by Posit), with support for installing many CRAN packages directly in the browser.

PyScript, built by Anaconda on top of Pyodide (with optional MicroPython for lighter-weight cases), exposes Python directly in HTML pages via <py-script> tags. Its focus is embedding Python in web pages, dashboards, and interactive demos rather than notebook workflows — a different authoring surface on the same underlying WebAssembly stack.

xeus family (QuantStack) is a C++ implementation of the Jupyter kernel protocol, plus a set of kernels built on it: xeus-python, xeus-r, xeus-cpp, xeus-lua, and others. These kernels wrap the respective language interpreters with a standardized communication interface, including what a notebook needs beyond a REPL — rich outputs (plots, tables, HTML), execution state, tab completion. Because xeus is compact C++ rather than Python, its kernels compile to WebAssembly and run inside JupyterLite via the jupyterlite-xeus extension, making the notebook UI genuinely multi-language. xeus kernels use language-agnostic Emscripten-Forge packaging.

Emscripten-Forge (originated at QuantStack) is a conda-style multilingual package ecosystem for WebAssembly, with several hundred scientific libraries and growing. Python packages, R packages, C/C++ libraries, Fortran, and standalone binaries fit the same model, which is how xeus-r, xeus-cpp, and xeus-lua get their dependencies. Its dependency solver, mambajs (also QuantStack), runs entirely in the browser, letting users find and install packages cross-language at runtime with no server call. Emscripten-Forge also ships pyjs, a low-level Python ↔ JavaScript foreign function interface for Emscripten-compiled Python — built on pybind11 (Python/C++ bindings) and Emscripten Embind (C++/JavaScript bindings). xeus-python uses it as its FFI (the same role Pyodide's built-in ffi plays on the Pyodide side), but it can also be used directly from a webpage that embeds Emscripten-compiled Python.

To put this in one picture: JupyterLite provides the UI, can be used for the familiar lab or notebook interfaces but is modular enough to be repurposed for other applications, like the REPL on try.jupyter.org; Pyodide and WebR provide monolithic Python and R runtimes with their own package paths and ecosystems (e.g. PyScript). Emscripten-Forge — with xeus kernels, mambajs, and pyjs alongside — provides a wider, multi-language, less monolithic experience.

Notebook.link — from stack to platform​

The stack above is the open in-browser scientific compute foundation. But running it at team, classroom, or enterprise scale usually needs an organisational layer on top: identity, storage, permissions, environment management, hosting, and integrations with the wider systems people already use. Notebook.link — the product this post is written for, built by QuantStack — is a proprietary platform that supplies exactly that. It adds single sign-on and access controls, user and group permission management, versioned compute environments with per-user persistent storage, hosted public environments shareable as a URL in different forms, AI integration inside the notebook experience, autograding and LMS integration (Moodle and others) for teaching workflows, and seamless switching to remote backend kernels — the classic Jupyter server model, reached through the same interface — when a workload needs GPU or larger hardware. It is available as a managed cloud service or as a self-hosted deployment on the customer's own infrastructure, for teams that need data and compute to stay in-house.

Fig above: A few examples from the notebook.link gallery — Bayesian inference, orbital mechanics, phylogenetic trees, Conway's Game of Life, and mixed-integer optimization, all written, shared and running fully in the browser. Try them yourself!

Where it fits​

Today, browser-native compute is often the right default for teaching and workshops, runnable documentation, interactive blog posts or tutorials, sharing quick analyses with a colleague, and exploratory data analysis on small-to-medium datasets. Community libraries increasingly attach JupyterLite or notebook.link badges to their own documentation example galleries as well, letting readers execute code directly next to it.

For workloads that genuinely need the full spectrum of what is possible on one's own machine or remote hardware — large simulations, model training, multi-core parallelism, GPU acceleration — browser-native compute alone is not the right tool. But the two models are complementary rather than competing: browser-native environments can serve as a lightweight front door to backend compute when heavier work is needed, and platforms like notebook.link can seamlessly switch between WASM and backend kernels as needed.

Notebook.link is a scientific computing platform with multilingual browser-native support built by QuantStack, contributors to JupyterLab, Mamba, JupyterLite, and Emscripten-Forge. Try it at notebook.link.

Sharing a Jupyter notebook has always been harder than it should be. You clone a repo, fight the environment, install conflicting dependencies, and hope the author didn't forget to pin their package versions. Half the time, you give up before the kernel even starts. Notebook.link fixes this. Open a link. Your notebook runs. That's it.

Built on JupyterLite, Notebook.link is more than just a notebook viewer: it’s a fully interactive, scalable, and language-agnostic computing environment that operates entirely in your browser. Whether you’re a data scientist, educator, researcher, or developer, Notebook.link eliminates the need for local installations or complex setups, allowing you to create, share, and execute notebooks effortlessly.

Why Notebook.link?​

1. Lightweight, Fast, and Accessible​

Notebook.link delivers instant access to notebooks, no server setup, software installation or configuration required. Simply follow a link and start working.

Notebook.link is powered by JupyterLite, a distribution of Jupyter running entirely in the Web browser, including language kernels and terminals. Unlike traditional JupyterLite deployments, your content is persistently stored in the cloud, enabling long-term projects without losing progress.

2. Scalable and Powered by WebAssembly​

Under the hood, Notebook.link leverages emscripten-forge, a WebAssembly software distribution built on the conda ecosystem (using mamba and rattler), and hosted on prefix.dev. This brings the full power of scientific computing to your browser, supporting Python, R, GNU Octave, and C++, all in one unified environment.

Our distribution extends beyond the Python programming language, with support for R, GNU Octave, C++, as well as console applications, making it a unified solution for the entire scientific computing community.

3. Multi-Language Support​

Thanks to the xeus kernel ecosystem, you can write and execute code in your preferred language, all within a single platform:

Python (via xeus-python) R (via xeus-r) C++ (via xeus-cpp) GNU Octave (via xeus-octave) Write, test, and share code in your preferred language, all within a single platform.

Therefore, the scope of emscripten-forge and Notebook.link expands beyond that of Pyodide (Python) or WebR (R). It is a consolidated software distribution for WebAssembly addressing the whole scientific computing community.

4. A Fully-fledged in-Browser Terminal Experience​

Need to run shell commands? Notebook.link includes an in-browser terminal that emulates bash, complete with WebAssembly builds of essential Unix commands like sed, grep, cat, and even vim and nano, bringing the essential developer tools to your Web browser.

We are not stopping here. Soon, you’ll be able to clone, commit, and push directly from the browser, making collaboration even smoother.

5. Permalinks for Seamless Sharing​

You can generate permalinks for any notebook, whether created on Notebook.link or hosted on GitHub. Say goodbye to “it works on my machine” issues. Share a permanent link, and anyone can run your notebook instantly.

Multiple sharing options are available:

Links to a full JupyterLab UI, with a tiled layout and all the advanced features of the JupyterLab environment. Links to a single-document view, providing a full-page Jupyter notebook interface. Links to a presentation view, turning notebooks into blog posts by removing distracting UI elements. You can explore the following demos:

R language demo​

Experience R in a Jupyter environment using the xeus-r kernel, running entirely in your browser.

Jupyter Games​

Tiny games and simulations built using Box2D and its Python bindings, pybox2d, and rendered with ipycanvas, utilising the presentation view.

In-browser C++ development​

Discover the capabilities of the C++ Jupyter kernel, including rich display and interactive help. Write and execute C++ directly in your browser.

6. An AI Assistant for Notebook.link​

Enhance your workflow with JupyterLite-AI, an integrated AI assistant compatible with most LLM providers. Import your API key and enjoy an augmented development experience with features like in-browser tool calling — which are based on the JupyterLab.

The JupyterLite-AI interface, powered by Mistral AI’s Devstral model.

Custom Deployments for Institutions​

We offer tailored deployments for universities, research labs, and enterprises. Host your own instance of Notebook.link, supporting both WebAssembly-based and classical Jupyter kernels, for seamless integration with existing workflows.

Unlike traditional JupyterHub deployments, where users wait for the environment to initialize, Notebook.link delivers an instant, interactive UI. Users can explore notebooks, browse files, and start working immediately, even while the kernel environment finalizes setup. This setup, based on the Jupyverse project, creates a frictionless experience for collaborators.

Interested in a custom deployment? Contact us at notebook@quantstack.net for inquiries and pricing.

A Long-Term Commitment to Open-Source​

Notebook.link stands on the shoulders of open-source giants, built upon the foundational work of the Jupyter community.

For over a decade, QuantStack has been a dedicated advocate and contributor to this ecosystem. Our commitment remains unwavering: we will continue to support and advance open-source innovation, just as we have done for years.

Our team includes more than 10 full-time contributors to the Jupyter project and ecosystem, and we actively maintain and enhance other critical components of the scientific computing ecosystem, such as Apache Arrow, conda-forge, mamba, and Xtensor.

At the heart of Notebook.link is JupyterLite, a cornerstone technology developed by QuantStack since 2021 and recently transferred to Jupyter governance. We are proud to uphold our tradition of leadership and collaboration, ensuring the continued growth and accessibility of these essential tools.