When we told people we were building a RAW photo editor that runs in a browser, the most common reaction was a version of: that's not possible. RAW files are huge. Decoding them is slow. Browsers aren't built for that.
All three of those things were true in 2012. They haven't been true for a while now.
What a RAW File Actually Is
A RAW file is the unprocessed sensor data from your camera. Where a JPEG is a compressed, processed image — with white balance baked in, noise reduction applied, and a tone curve embedded — a RAW file is closer to a digital negative. It records exactly what the sensor saw, in the camera's native bit depth (usually 12 or 14 bits per channel), before any of the processing decisions that turn sensor data into a photograph.
This is why photographers shoot RAW: the processing decisions are yours to make, not the camera's. Recover a blown highlight. Pull shadow detail out of a dark corner. Adjust white balance without any quality loss. A RAW file gives you that flexibility. It also gives you a large, proprietary, and complex binary format that requires specific decoding logic to read.
Each camera manufacturer uses their own RAW format. Canon uses CR2 and CR3. Nikon uses NEF. Sony uses ARW. Fuji uses RAF. Each has different compression schemes, different metadata layouts, different color matrix specifications. Supporting all of them is not a small problem.
Why Browsers Can Handle This Now
The modern browser is not the document renderer of 2005. It is a full application runtime with access to a low-level instruction set called WebAssembly, a hardware-accelerated graphics pipeline called WebGL, multi-threaded execution via Web Workers, and near-native I/O performance via the File System Access API. Taken together, these capabilities make the browser a viable environment for computationally intensive software — including photo editing.
WebAssembly is the key piece. It lets us compile C and C++ code — the same languages used in native desktop applications — to a binary format that runs in the browser at close to native speed. The RAW decoding libraries that power professional software have existed for years. With WebAssembly, we can run them in your browser tab.
“WebAssembly is quietly one of the most significant developments in software in the last decade. It makes the browser a deployment target for almost any program, not just ones written in JavaScript.”
— PhotoMonk team
What Actually Happens When You Open a File
When you drag a CR2 into PhotoMonk, a few things happen in sequence. First, the File API reads the file from your disk into browser memory — this never touches a network. Then a WebAssembly module decodes the RAW data: it reads the sensor array, applies the camera's color matrix to convert from the sensor's native color space to a standard one, and demosaics the raw pixel data into a full-color image.
The result is a high-bit-depth image buffer — typically 16 bits per channel — that gets passed to a WebGL shader running on your GPU. From that point forward, every adjustment you make — exposure, shadows, HSL, curves — is a GPU operation. The shader recalculates in real time for every slider change, which is why the preview updates without any perceptible lag.
The whole pipeline — decode, transfer to GPU, render — typically takes two to four seconds for a 20-25MB file. That's on the same order as a native desktop application opening the same file.
The Limits
This doesn't mean the browser can do everything a desktop application can. Very large files — above 50MB or so — will strain browser memory limits on lower-end devices. The WebAssembly RAW decoder, while fast, is doing work that dedicated native code can do faster with more aggressive hardware access. For batch processing hundreds of files, a desktop application is still faster.
But for the use case PhotoMonk is built for — opening a file, editing it, exporting it — the browser handles it well. No installation, no version to update, no platform to worry about. The same editor works on Windows, macOS, Linux, and Chromebooks, because it runs where the browser runs.
Why This Matters Beyond PhotoMonk
The browser as application runtime is a trend that's still unfolding. CAD tools, code editors, video editors, audio workstations — software that was firmly desktop territory a few years ago is increasingly browser-native. The performance ceiling is still lower than native, but it's rising, and the distribution advantages — no install, runs everywhere, instant updates — are significant.
We built PhotoMonk in the browser because it was the right technical choice for what we wanted to build. We think it's also a preview of where a lot of creative software is heading.
Curious how it performs on your machine? Open a RAW file and see. It takes about thirty seconds to know whether the browser-based approach works for your workflow.