Appearance

Language

English Español Français Deutsch Italiano Português 日本語 Русский 한국어 中文 (简体) 中文 (繁體) العربية Български Català Nederlands Ελληνικά हिन्दी Bahasa Indonesia Bahasa Melayu Polski Svenska ภาษาไทย Türkçe Українська Tiếng Việt

How RoundCut works

Technical detail on how the tools run entirely in your browser — and how you can verify it yourself.

The short answer

RoundCut runs every tool in your browser using two browser-native APIs: the HTML5 Canvas API for pixel-level operations, and WebAssembly for the heavier work — image format encoding/decoding and AI inference. Nothing is uploaded. Nothing is processed on our servers, because we don’t run servers that touch your files.

You can verify this in about 30 seconds: open your browser’s DevTools, switch to the Network tab, clear the log, and use any tool. The only network requests you’ll see are for static site assets — HTML, CSS, JavaScript, fonts, the WebAssembly modules. Your image never leaves the page.

Why client-side

Most online image tools work the other way around: you upload, a server processes, you download the result. That model has a few well-known downsides — your file lives on someone else’s machine, you wait for the round-trip twice, and the operator pays per CPU-second of work, which is why those services tend to add accounts, watermarks, or paid tiers.

Browsers have been able to do most of this work natively for years. The <canvas> element handles cropping, rotating, resizing, and re-encoding; WebAssembly lets us run the same MozJPEG, libwebp, libavif, and Oxipng C/Rust libraries that Squoosh uses, at near-native speed. By the time we shipped the 2026 rebuild, the browser had effectively caught up to the desktop image-editing toolkit. There was no longer a reason to involve a server.

The result is a stack with three properties that compound: privacy (your file never leaves your device), speed (no upload, no queue, no server round-trip), and cost (we serve static assets from a CDN for cents per month, regardless of how many people use the tools).

The pipeline, step by step

1. You select a file

When you pick an image — through the file picker, drag-and-drop, or paste — the browser hands JavaScript a File object. JavaScript reads the bytes using the FileReader or Blob.arrayBuffer() API. At no point in this step is the file sent over the network.

2. The browser decodes the image

Modern browsers can natively decode JPG, PNG, WebP, GIF, AVIF, and (on Safari and recent Chromium) HEIC. We use createImageBitmap() to turn the raw bytes into a bitmap the GPU can work with, off the main thread. For HEIC on browsers that don’t decode it natively, we fall back to a WebAssembly decoder that runs locally in your browser.

3. The tool does its thing

What happens next depends on the tool. RoundCut currently ships three:

  • Circle Crop — a Canvas 2D pixel transform with a circular clip path. The bitmap is drawn into a <canvas> at the chosen rotation and zoom, the circle clip is applied, and the inside of the circle is read back as an ImageData. Cropper.js handles the interactive crop frame.
  • Compress — re-encodes JPG, PNG, WebP, or AVIF using jSquash WebAssembly modules (MozJPEG, libwebp, libavif, Oxipng). These are the same upstream codecs used by Squoosh. They run in a Web Worker so the UI stays responsive while a multi-megapixel photo is being encoded, and a side-by-side preview lets you see the trade-off before committing.
  • Remove Background — a small ONNX-format AI model (a few MB, downloaded once and cached) runs in your browser via ONNX Runtime Web, with WebAssembly as the execution backend. The first run downloads the model; every run after is local and instant.

4. You download the result

The output bitmap is encoded into a Blob, wrapped in an object URL, and offered to your browser’s standard file-save dialog. Where supported, we use the File System Access API so you can pick the destination folder directly. The file appears on your disk; nothing transits a server.

How to verify it yourself

The “no upload” claim is checkable in two minutes. Pick whichever of these you prefer:

Method 1 — Watch the Network tab

  1. Open RoundCut in a fresh tab.
  2. Open DevTools (F12 or Right-click → Inspect) and switch to the Network tab.
  3. Click the “clear” button in the Network tab to start fresh.
  4. Use any tool: upload an image, edit it, download the result.
  5. Look at the Network log. You’ll see requests for HTML, CSS, JS, fonts, and (on first use of a heavier tool) the relevant WebAssembly module. You will not see any request that contains the bytes of your image.

The “Initiator” column tells you which script triggered each request, and the “Type” column tells you what was sent. Filter by “Fetch/XHR” to focus on data requests; you’ll see they’re all small, all to the static origin, and none contain your file.

Method 2 — Use the tools offline

  1. Load any RoundCut tool page. Use it once to make sure the relevant WebAssembly modules are cached.
  2. Open DevTools, go to the Network tab, and tick the Offline checkbox (or simply turn off your Wi-Fi).
  3. Reload the page. It still loads, because the browser cached the static assets.
  4. Use the tool again, end to end. It still works.

If the tool worked offline, by definition it did not contact a server during the operation. This is the strongest possible proof — the work happened on your machine because there was no other machine reachable.

What we do see

To be clear about what is collected: when you load a page, our analytics provider (Cloudflare Web Analytics) records that some browser loaded that URL from some country. No cookies, no persistent identifiers, nothing tied to a person.

For tools that download a WebAssembly module on first use (jSquash codecs, the ONNX background-removal model), our hosting provider sees that someone fetched the module — the same way it sees them fetch the CSS file. The module itself contains no information about your image.

The full data inventory is in our privacy policy.

The technology stack

For the curious, here’s what RoundCut is built on:

  • Astro — the static site generator. Every page ships as plain HTML with progressively-enhanced JavaScript “islands” only where interactive tools live.
  • Vanilla CSS with custom properties — no Tailwind, no CSS-in-JS. The full design system is a single tokens.css file.
  • jSquash — WebAssembly bindings to MozJPEG, libwebp, libavif, and Oxipng for image encoding.
  • Cropper.js — the crop-rectangle interaction layer for the cropping tools.
  • ONNX Runtime Web — runs the background-removal model in your browser via WebAssembly.
  • Cloudflare Pages — hosts the static build, serves it from the edge, and provides DNS plus DDoS protection.
  • Cloudflare Web Analytics — aggregate, cookie-less page-view counts.

Browser support

Every tool works on the current and previous version of Chrome, Firefox, Safari, and Edge — desktop and mobile. The site uses progressive enhancement: where a browser supports a newer API (e.g. showSaveFilePicker, OffscreenCanvas), we use it; where it doesn’t, we fall back to the older equivalent. There is no “your browser is not supported” wall.

The only hard requirement is JavaScript. With JavaScript disabled, the tools cannot run — there is no server-side fallback because there is no server doing image work in the first place.

Questions

Anything we didn’t cover? Email support@araluma.com. Technical questions welcome.