Browser-based compilers run your code inside the web page itself, using WebAssembly: a compact, sandboxed binary format that browsers translate into fast machine code. Real compilers and interpreters such as Clang, CPython, R and SQLite are themselves compiled to WebAssembly, downloaded once, and then compile or run your program on your own device, with nothing sent to a server. Traditional online compilers work the other way round, uploading your code to a server that runs it and sends back the output.
- WebAssembly is a portable compile target that all major browsers run at speeds close to native code, inside the same security sandbox as JavaScript.
- Our C and C++ compilers run Clang in the tab: it turns your code into a WebAssembly module, which is then executed with a small WASI layer that supplies input and output.
- Python, R, SQL, Ruby, PHP, Lua and Prolog run as WebAssembly builds of their official interpreters; JavaScript-family languages use the browser's own engine.
- Running locally means privacy, no server queue and offline use once the runtime is cached.
- The trade-offs are a one-off download, no threads or network sockets, a temporary in-memory file system and, in our C++ build, no exceptions.
What WebAssembly is
WebAssembly (often shortened to Wasm) is a low-level instruction format designed as a compile target. You do not usually write it by hand. Instead, a compiler such as Clang or Rust's compiler produces a .wasm file from ordinary source code, in the same way it would produce an executable for an x86 or ARM processor. The format is an open standard developed at the W3C, documented at webassembly.org, and supported by Chrome, Edge, Firefox and Safari.
Three properties make it useful for running code in a browser:
- Portable. The same
.wasmfile runs on Windows, macOS, Linux, Android and iOS, on any processor, because the browser translates it into the local machine code. - Fast. WebAssembly is typed and close to the hardware, so browser engines can compile it ahead of execution into efficient machine code. CPU-heavy code typically runs much faster than equivalent JavaScript and in the same general range as native code, although usually somewhat slower.
- Sandboxed. A WebAssembly module gets a block of private memory and can only call the functions it is explicitly given. It cannot read your files, open network connections or touch the rest of the page unless the host code provides a way to do so.
WASI: a system interface for WebAssembly
A C program expects an operating system: something to read standard input from, write output to, open files and get the time. WebAssembly has none of that built in. The WebAssembly System Interface (WASI) defines a standard set of such functions that a WebAssembly program can import. Outside the browser, runtimes such as Wasmtime implement WASI on top of a real operating system. Inside a browser, a small JavaScript library called a WASI shim implements those functions on top of in-memory data.
How traditional online compilers work
Most long-established online compilers and coding-exercise sites run your code on their servers:
- Your browser sends the source code (and any input) to the website's server.
- The server places it in an isolated environment, typically a container or lightweight virtual machine, with limits on time, memory and processes.
- The real compiler or interpreter installed there builds and runs the program.
- The output is captured and sent back to your browser, and the environment is discarded.
This model has real advantages. The server can offer almost any language and version, full operating-system features such as threads and processes, and sometimes network access and large libraries. But your code leaves your device, busy services may queue requests, every run depends on a network round trip, and the operator must pay for computing power for every execution, which is why many limit runs or require an account.
How our in-browser compilers work
On our online compilers, the runtime for each language is downloaded into your browser and run inside a Web Worker, a background thread that keeps the page responsive while your program runs. A time limit and a Stop button let the page terminate the worker if a program runs too long, for example because of an infinite loop. Runtime files are pinned to exact versions, and most are checked against a cryptographic hash before they are executed.
C and C++: a real compiler in the tab
The C compiler and C++ compiler use Clang 21, the LLVM-based compiler, packaged as WebAssembly by the YoWASP project. Each run happens in two stages:
- Compile. Clang, itself running as WebAssembly, compiles your
main.cormain.cppwith optimisation and warnings enabled (C17 or C++20). Its output is not an x86 or ARM executable but a new WebAssembly module that targets WASI. Compiler warnings and errors are shown exactly as Clang prints them. - Run. The browser compiles that module to machine code and starts it with a WASI shim. The shim connects standard input to the text in the input box and sends standard output and standard error to the output panel.
In other words, a compiler compiled to WebAssembly produces your program compiled to WebAssembly, and both run in the same tab.
Interpreters compiled to WebAssembly
| Language | Runtime | What it is |
|---|---|---|
| Python | Pyodide | CPython, the reference Python interpreter, compiled to WebAssembly. Packages such as NumPy and pandas are also prebuilt for it. |
| R | webR | The official WebAssembly build of R, including base graphics. |
| SQL | sql.js | The SQLite database engine compiled to WebAssembly, with the database held in memory. |
| Ruby | ruby.wasm | The official CRuby interpreter built for WASI, with its standard library. |
| PHP | php-wasm | The PHP interpreter compiled to WebAssembly. |
| Lua | wasmoon | The reference Lua 5.4 interpreter compiled to WebAssembly. |
| Prolog | swipl-wasm | SWI-Prolog compiled to WebAssembly. |
Because these are the same interpreters people install on their computers, behaviour and error messages match the desktop versions closely. You can try them on the Python compiler, the R compiler and the SQL compiler.
Languages that use the browser's own engine
Some languages need no WebAssembly at all. The JavaScript compiler runs code directly in the browser's JavaScript engine. TypeScript and CoffeeScript are translated into JavaScript by their official compilers, which are distributed as JavaScript, and the result is then run the same way. Scheme uses BiwaScheme and Clojure uses SCI (the Small Clojure Interpreter), both interpreters that themselves run as JavaScript.
Advantages of running code in the browser
- Privacy. Your source code and input stay on your device. They are not uploaded, stored or logged by our server, because the server never receives them.
- No queue and no account. Each visitor uses their own processor, so there is no shared execution queue and no need to ration runs.
- Works offline after loading. Once the page and runtime have been downloaded and cached, you can keep editing and running code if your connection drops, as long as the tab stays open. Extra packages that load on demand, such as some Python libraries, still need a connection the first time.
- Fast repeat runs. After the first load, interpreted languages start almost instantly, and there is no network round trip between pressing Run and seeing output.
Limits and trade-offs
| Limit | Why it exists | What it means in practice |
|---|---|---|
| Download size | The whole compiler or interpreter has to reach your browser. | Clang, R and Ruby are tens of megabytes; Lua and SQLite are under one. Later visits use the browser cache. |
| No threads | Our runtimes run single-threaded; WebAssembly threads need extra browser isolation settings and runtime support. | pthread, std::thread or Python's threading for real parallelism will not work as on a desktop. |
| No network sockets | The sandbox gives programs no way to open raw network connections. | Code that opens sockets or makes HTTP requests from C, Python or R will fail. Browser JavaScript can still use fetch. |
| No real file system | Runtimes get, at most, an in-memory virtual file system, never your disk. | Python and some other runtimes can create files during a session, but they vanish when the page closes; our C and C++ programs only get standard input and output. |
| No C++ exceptions | Our C++ build is compiled with exceptions disabled (-fno-exceptions). | Code using try, catch or throw will not compile; use return values or error codes instead. |
| Memory | 32-bit WebAssembly can address at most 4 GiB, and browsers or devices may allow less. | Very large arrays or data sets can fail with out-of-memory errors, especially on phones. |
| Input is not interactive | Standard input is supplied before the program starts. | Type all input in the input box first; prompts cannot wait for you mid-run. |
For learning, testing algorithms and coursework, these limits rarely matter. For programs that need networking, multiple processes or lots of memory, use a local installation or a server-based environment.
The security model
Running arbitrary code sounds risky, but in-browser compilers rely on protections that browsers already apply to every website.
- WebAssembly isolation. A module can only read and write its own linear memory, which is bounds-checked, and can only call functions explicitly imported into it. A C program with a buffer overflow can corrupt its own memory, but it cannot escape into the browser or the operating system.
- The browser sandbox. All page code, including WebAssembly and Web Workers, runs inside the browser's process sandbox and same-origin rules, so it cannot read other sites' data or your files.
- Workers and time limits. Running in a worker means a runaway program can be terminated without freezing or reloading the page.
- Verified runtimes. Pinning exact runtime versions, and checking hashes where the loading method allows it, protects against a content delivery network silently serving a different or modified file.
One caveat: JavaScript you run in the JavaScript compiler has the same abilities as any script on a web page, including making network requests. As with any code, only run snippets you understand, especially ones copied from strangers.
When to use which kind of online compiler
- If your code is private, for example coursework or work code, prefer an in-browser compiler so it never leaves your device.
- If you need threads, sockets, a specific system library or a language without a WebAssembly build, use a server-based service or a local installation.
- If you are on a slow or metered connection, start with the lighter runtimes; the first load of a large one is the main cost.
Frequently asked questions
Is my code sent to a server when I use your online compilers?
No. The page downloads the compiler or interpreter, and your code and input are compiled and run on your own device. The server only delivers the page and the runtime files.
Is WebAssembly as fast as native code?
It is usually close but somewhat slower, and the gap depends on the workload and the browser. For typical exercises and algorithms the difference is not noticeable; the first-time download is the bigger delay.
Why does the first run take longer?
The first run downloads and initialises the runtime, which for Clang, R or Ruby means tens of megabytes. The browser caches these files, so later visits start much faster.
Why does my C++ code with try and catch not compile?
Our C++ build is compiled with exceptions disabled, because exception handling in WebAssembly needs extra support from the toolchain and runtime that this setup does not use. Rewrite error handling to use return values, std::optional or error codes, or compile locally if you need exceptions.
Can a program in an online compiler harm my computer?
Code running as WebAssembly in the browser is confined to its own memory and the functions the page provides, and the browser sandbox adds another layer. It cannot read your files or install software. JavaScript code can still make web requests like any page script, so avoid running code you do not trust.