TeXbrain: A LaTeX Editor Running pdfTeX in the Browser via WebAssembly

A Zero-Installation LaTeX Editor

For researchers, students, and technical writers, LaTeX is practically the standard tool for typesetting mathematical formulas and academic papers. But its learning curve has always been steep: a TeX Live distribution that can easily weigh several gigabytes, complex package management, and environment configuration headaches often discourage newcomers before they even write their first line of markup.

Recently, a project called TeXbrain caught attention on Hacker News. Its core pitch is refreshingly simple: it's a LaTeX editor that runs entirely in the browser, executing the pdfTeX engine locally via WebAssembly (WASM).

In other words, you don't need to install any software, create an account, or rely on a remote server to compile your work. Just open a webpage and start writing LaTeX with real-time PDF output.

How WebAssembly Changes the Way We Use LaTeX

From Server-Side Compilation to Local Browser Compilation

Traditionally, browser-based LaTeX editors like Overleaf have been cloud compilation solutions: you type code in the browser, it's sent to a remote server, the TeX engine compiles it there, and the resulting PDF is returned to you. This approach eliminates local installation, but comes with clear downsides — it requires a network connection, introduces latency, raises privacy concerns (your documents are uploaded to a third-party server), and involves significant server infrastructure costs.

TeXbrain takes a different approach. By leveraging WebAssembly, it compiles the pdfTeX engine — originally written in C — into a binary format that runs inside the browser's sandbox. This means the entire compilation process happens on your own machine, with the browser tab serving as the runtime environment.

WebAssembly (WASM) is a low-level binary instruction format standardized by the W3C, designed to let programs written in systems languages like C, C++, and Rust run in the browser at near-native speed. Unlike JavaScript, WASM code is compiled into compact bytecode before execution, and the browser's WASM virtual machine efficiently translates it into machine instructions. In TeXbrain's case, developers use toolchains like Emscripten to cross-compile pdfTeX's C source code into a .wasm module, which is then loaded and invoked in the browser via JavaScript glue code. Since WASM runs inside the browser's security sandbox, it cannot directly access the user's file system or network — so a virtual file system (such as Emscripten's MEMFS) is also needed to simulate the directory structure and file I/O operations that pdfTeX depends on.

Real-World Advantages of Local Browser Compilation

• Stronger privacy: Document content never leaves your machine, making it suitable for sensitive research drafts or unpublished papers.
• Offline potential: Once resources are loaded, compilation can theoretically continue without a network connection.
• Zero backend costs: For developers, there's no need to maintain expensive compilation server clusters — pure static hosting is sufficient.
• Instant usability: No need to sit through the lengthy TeX Live installation process or consume gigabytes of disk space.

Technical Challenges and Practical Trade-offs

Bringing a full TeX engine into the browser is no small feat, and it's one of the most technically interesting aspects of projects like this.

On-Demand Loading of Packages and Font Resources

Much of LaTeX's power comes from its vast ecosystem of packages and font libraries. The complete TeX Live distribution is enormous and cannot realistically be bundled into a browser download all at once. WASM-based pdfTeX implementations therefore typically use an on-demand loading strategy: resources are only fetched when a document actually references a particular package or font.

This works reasonably well for common documents on first compile, but can lead to missing resources or slow loading times when obscure packages or complex font configurations are involved. This is the most significant capability gap between browser-based TeX solutions and a full local installation.

pdfTeX is one of the most widely used variants in the TeX engine family. Building on the classic TeX engine, it adds the ability to output PDF directly and includes built-in support for micro-typographic features such as character protrusion and font expansion. Common LaTeX packages are pre-defined collections of commands and styles — for example, amsmath for advanced math typesetting, graphicx for image insertion, and hyperref for generating hyperlinks. A full TeX Live distribution contains over 4,000 packages and can exceed 7–8 GB when unpacked. Browser-based solutions typically preload only the most essential packages (such as the core LaTeX packages and AMS math bundle), fetching the rest via HTTP requests on demand — which explains why noticeably longer compile times can occur when using less common packages for the first time.

Performance and Memory Constraints

Browser sandboxes impose certain limits on memory and computational resources. For short documents and standard math typesetting, WASM-based pdfTeX performs impressively well. However, when dealing with large documents spanning hundreds of pages, projects with extensive figures, or complex cross-references, native local compilation still holds a clear speed advantage.

Who TeXbrain Is Best Suited For

Tools like TeXbrain occupy a well-defined niche. They're not meant to replace a professional user's full TeX environment — they fill specific use-case gaps:

• Occasional formula writers: For quickly drafting a note with mathematical symbols or formatting a formal letter on the fly.
• LaTeX beginners: No installation friction to push them away — they can dive straight into syntax in the browser.
• Privacy-conscious writers: Those who don't want to upload their documents to a cloud compilation service.
• Teaching and demonstration: Instructors can have students open a webpage and start practicing LaTeX immediately, without the hassle of setting up a uniform local environment.

The Bigger Trend: WASM Is Bringing Heavy Desktop Tools to the Browser

TeXbrain's significance extends beyond LaTeX itself. It's another prime example of the broader trend of WebAssembly enabling traditional desktop-class applications to run in the browser.

We've already seen Python (Pyodide), SQLite (sql.js), FFmpeg, and even full Linux systems running inside browsers. These projects collectively demonstrate one thing: with WASM, the browser is evolving from a "document display platform" into a "general-purpose computing platform." Tools that once required cumbersome installation and cross-platform compatibility headaches can now be accessed by simply opening a link, with the added security benefit of sandbox isolation built in.

For developers, this model dramatically reduces distribution and maintenance costs. For users, it means a lower barrier to entry and better privacy protection. TeXbrain is a small but elegant embodiment of this wave.

The WASM projects mentioned above each represent distinct application directions. Pyodide compiles the CPython interpreter along with scientific computing libraries like NumPy and Pandas into WASM, enabling complete data science workflows in the browser — and it's been widely adopted by projects like JupyterLite. sql.js brings the SQLite database engine to the browser, allowing frontend applications to run SQL queries directly without any backend. FFmpeg.wasm enables heavy media operations like transcoding and video editing on the client side, avoiding the privacy and bandwidth issues of uploading user media files to a server. The common pattern across all these projects is: using Emscripten or WASI (WebAssembly System Interface) to port mature C/C++ codebases to browser runtimes — reusing decades of accumulated code assets while gaining the Web platform's distribution advantages of zero installation, cross-platform compatibility, and sandbox isolation.

Closing Thoughts

TeXbrain uses WebAssembly to pack pdfTeX into the browser, addressing a persistent pain point in LaTeX's history: the barrier of installation and configuration. It may not satisfy every professional user's need for a complete package ecosystem and high-performance compilation, but for the many lightweight, privacy-conscious, and instant-access use cases out there, it offers an elegant answer.

More importantly, projects like this remind us of the broader potential of WASM technology. As more and more heavyweight tools gain the ability to run natively in the browser, the way software is distributed and used is being quietly, but fundamentally, reshaped.