Skip to content
Published on

Real Engines in Your Browser: A Tour of WebAssembly Dev Tools

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Introduction — No Install, No Server, No Data Leaving Your Browser

Over the past few weeks I have added a pile of browser tools to this site: a Python interpreter, a PostgreSQL database, a video converter, even an x86 PC emulator. They all share one thing. They are not imitations — they are the real thing. The Python playground actually runs CPython; the SQL playground runs real SQLite. And all of it happens with no backend, inside your browser tab.

The technology that makes this possible is WebAssembly (WASM for short). This post is not marketing copy — it is about what WASM actually solved, what it still cannot do, and how to use the tools built on top of it.

Why WebAssembly Changed the Game

WebAssembly is a low-level bytecode format that runs in the browser. It is not trying to replace JavaScript; it takes on the jobs JavaScript was bad at. There are four core benefits.

  • Near-native speed: WASM is a precompiled binary format, so it parses fast and executes close to machine code via JIT/AOT. Heavy engines written in C, C++, or Rust run at practical speeds.
  • Language portability: Almost any language that compiles through LLVM or a dedicated toolchain can be ported to WASM. Existing C/Rust codebases like CPython, CRuby, SQLite, and ffmpeg come to the browser nearly as-is.
  • Sandboxed isolation: A WASM module runs in a sandbox with memory and system access blocked by default. It can only use capabilities the host (JavaScript) explicitly hands it, which makes it safe for running untrusted code.
  • No server + privacy: Because all computation happens client-side, no server is needed. As a result, your input data never leaves the browser. You do not have to upload your photos, code, or documents.

That last point matters a lot in practice. When you convert an iPhone HEIC photo or pick apart company logs with SQL, the fact that the data is never transmitted to any server is not just a convenience — it is a security requirement.

How a WASM Module Loads

Roughly, here is how the browser runs a WASM tool.

  1. Page loads
        |
        v
  2. Download the .wasm binary (CDN or self-hosted)
        |
        v
  3. WebAssembly.instantiate() compiles + instantiates
        |
        v
  4. JavaScript injects host functions (files, console, etc.)
        |
        v
  5. Engine runs — from here on, all compute is local

The .wasm file is fetched from a CDN or hosted directly by the site. Large runtimes like Python can be several to tens of megabytes, so the first load takes time. The browser then caches the file, so subsequent loads are much faster. That is why it is "slow only the first time, then instant."

One caveat is the isolation requirement. Heavy WASM tools that use threads or shared memory (SharedArrayBuffer) may require the browser's cross-origin isolation (COOP/COEP) headers. The multithreaded build of ffmpeg is the classic case. The site has to set those headers correctly for the feature to switch on.

Language Playgrounds — Real Interpreters Running

The most intuitive use is putting an entire programming language into the browser. These are not editors that merely do syntax highlighting; they run actual interpreters.

  • The Python Playground runs real CPython 3.14 compiled via Pyodide. print output is captured directly, and you can install numpy on demand.
  • The Ruby Playground runs CRuby 3.4 via ruby.wasm. Blocks, classes, and pattern matching behave with true Ruby semantics.
  • The PHP Playground runs PHP 8.3 on the WordPress Playground WASM engine.
  • The Lua Playground runs Lua 5.4 via wasmoon, tables, metatables, and coroutines included.

As a simple example, drop this into the Python playground and you get an immediate result with no server round-trip.

def fib(n):
    a, b = 0, 1
    for _ in range(n):
        a, b = b, a + b
    return a

print([fib(i) for i in range(10)])
# [0, 1, 1, 2, 3, 5, 8, 13, 21, 34]

The key point is that this output is not a "pre-saved answer." Change the code and the real interpreter runs again.

Databases and Data Tools — SQL in the Browser

The data tools show off WASM especially well, because a real database engine spins up inside the tab.

  • The SQL Playground runs real SQLite via WASM. Practice JOIN, GROUP BY, and window functions on sample DBs and export results to CSV.
  • The PostgreSQL Playground runs real PostgreSQL 18 via PGlite. JSONB, full-text search, recursive CTEs, and EXPLAIN ANALYZE all work with genuine Postgres syntax, and you can persist data in IndexedDB.
  • The DuckDB Data Playground analyzes CSV, JSON, and Parquet with SQL via DuckDB-Wasm. You can use analytics-focused syntax like SUMMARIZE and PIVOT.
  • The jq Playground transforms JSON with jq filters in real time.

For instance, this recursive CTE actually executes in the Postgres playground.

WITH RECURSIVE counter(n) AS (
  SELECT 1
  UNION ALL
  SELECT n + 1 FROM counter WHERE n < 5
)
SELECT n, n * n AS square FROM counter;

Since data never leaves the browser, you can safely paste in and analyze a sensitive CSV. That is a property most online SQL tools cannot offer.

Build and Compile Tools — The Toolchain Inside the Browser

Build tools are exactly the area that craves native performance, and thanks to WASM they came to the browser too.

  • The SWC Playground runs SWC, the ultra-fast Rust compiler, to transpile TypeScript/JSX and even show the AST.
  • The esbuild Playground transforms and bundles via esbuild-wasm.
  • The Sass/SCSS Compiler compiles SCSS to CSS with dart-sass.
  • The Graphviz Renderer draws DOT-language diagrams as SVG.
  • The Typst Playground runs the Rust-based Typst typesetting engine to produce LaTeX-alternative documents as PDF.
  • WebAssembly Studio compiles WAT (WebAssembly Text) to a binary with wabt, shows the hex dump and disassembly, and actually runs it. It is learning WASM with WASM.

Their common trait is the absence of "install hell." No node_modules, no local toolchain — just open the link and the compiler runs.

Media and Images — ffmpeg and ImageMagick, Whole

Media processing was traditionally the domain of heavy native libraries. Those run in the browser now too.

  • The Video Converter uses ffmpeg.wasm to make GIFs, extract audio, and handle trimming, resizing, and speed changes. No file upload.
  • The ImageMagick Universal Image Converter uses the real ImageMagick engine (WASM) to read iPhone HEIC, TIFF, PSD, and 270-plus formats and convert to JPG, PNG, WebP, and AVIF.
  • The OCR Text Extractor extracts Korean, English, and Japanese text from images via Tesseract WASM.
  • The ASCII Art Converter turns photos into character art.

Video conversion is a good example of WASM's limits and strengths at once. It is slower than native ffmpeg, but making a short clip into a GIF is perfectly practical — and, crucially, the video file is never uploaded to a server.

Other Tools — AI, Emulators, Simulators

WASM's applications go beyond languages and media.

  • The Browser AI Lab runs sentiment analysis, embedding similarity, Korean-English translation, zero-shot classification, and summarization with no server via Transformers.js (the ONNX runtime). With WebGPU available, it even uses GPU acceleration. Your input text is never transmitted anywhere.
  • The PC Emulator in Browser boots a real x86 PC via v86. Boot FreeDOS in one click or boot your own .img/.iso image.
  • The Git Playground, Web Terminal, and Linux Terminal simulate command-line practice environments.
  • The eBPF Playground simulates the eBPF instruction set and kernel verifier. (It is for learning the concepts, not a real kernel hook.)
  • The Crypto & Hash Lab and Cipher Lab let you practice Argon2, SHA/HMAC, AES-GCM, RSA/ECDSA, and classical ciphers and cryptanalysis, all client-side.

Two threads run through this list. One is bringing real engines (AI models, an x86 CPU, crypto libraries) to the browser via WASM; the other is simulators that visualize concepts (the git graph, the eBPF verifier). The latter do not run real systems, but they are optimized for grasping the principles visually.

Realistic Limits — What WASM Cannot Do

WASM is powerful but not magic. There are limits worth knowing before you reach for these tools.

  • First-load size: Large runtimes like Python or Postgres download several to tens of megabytes. Caching helps, but the first visit is slow.
  • Slower than native: It is near-native, not native itself. Heavy video encoding or large-scale data processing is slower than native tools.
  • No direct system access: Being a sandbox, it cannot freely touch the arbitrary file system, network sockets, or the GPU. It only uses browser-permitted APIs (File System Access, WebGPU, and so on). That is why even a tool like v86, which boots a real Linux kernel, actually runs on top of emulated hardware.
  • Memory ceiling: Baseline WASM uses a 32-bit address space, so memory is capped (the Memory64 proposal is easing this). Very large datasets are a strain.
  • Multithreading is conditional: Using threads requires the isolation headers mentioned earlier, and they are not enabled in every environment.

In short, WASM is ideal for "moderately heavy work, with no server and with privacy preserved." Extremely large or extremely high-performance work is still better on a server or natively.

Wrapping Up

The essence of the change WebAssembly brought is "using heavy tools in the browser, with no install and no data leaving." Real CPython, real PostgreSQL, and real ffmpeg run inside your tab, and neither code nor data goes out in the process.

The limits are clear. The first load is slow, and it is a poor fit for extreme performance. But for most everyday tasks — learning, experimenting, handling sensitive data — it is more than enough. Open the linked tools one by one. The fact that this much works with no server is genuinely surprising.

References

Discuss on Twitter • View on GitHub