Crop

Circle crop image Crop image

Optimize

Compress image Remove background Upscale image

Modify

Resize image

Convert

Other

Convert JPG to PDF

How RoundCut works

Technical detail on what each tool does, where it runs, and how you can verify it yourself.

The short answer

RoundCut uses a hybrid architecture: most tools run entirely in your browser with zero upload, and a handful route a single network request through our own infrastructure when the browser cannot match the quality, always with an invisible client-side fallback. We tell you which path you’re on, in every tool and on this page.

The table below is representative, not exhaustive (new tools ship regularly). It shows one example of each kind of path:

Example toolWhere the work happens
Circle Crop (browser-only)100% in your browser, Canvas API. No upload, works offline.
Compress preview (browser-only)100% in your browser, canvas.toBlob. No upload. The slider stays instant.
Compress final download (server-touching)One round-trip to our service at api.roundcut.com.br (Fastify + sharp + libvips on a VPS in Germany), with a browser fallback.
Remove Background (server-touching)One round-trip to a Cloudflare Worker that runs BiRefNet on Cloudflare’s edge GPUs, with a WebAssembly fallback in your browser when the cloud is unreachable.

Cropping, resizing, format conversion (except AVIF encoding), and the compress preview all run fully in your browser. Background removal, the compress download, AI upscaling, AVIF encoding, and multi-image PDF each route a single request and fall back to the browser when the cloud is unreachable.

You can verify the client-side claims in about 30 seconds: open DevTools → Network, clear the log, then use a browser-only tool like Circle Crop or the Compress preview slider, you will see zero requests carrying your image bytes leave the page. For the server-touching tools you will see exactly one upload per operation, to named endpoints.

Why hybrid

Most online image tools sit at one extreme: upload-everything-to-a-server (you wait for round-trips and the operator keeps your file), or all-in-browser (you pay quality and speed on the encode/AI steps). Neither extreme wins everywhere.

We picked client-side where browsers are already excellent, the <canvas> element handles cropping, rotating, resizing, and the lossy preview encode in JPG/WebP, and server-side where the browser still measurably loses:

  • Image compression, on the final download. Server-side sharp + libvips 8.17 produces files 10-15% smaller byte-for-byte than browser encoders at the same visual quality, and gives access to AVIF speed/chroma tuning and JPEG XL output that the browser doesn’t expose. The slider/preview still runs in your browser so iteration stays instant, only the “Download” tap goes through our service.
  • AI background removal and AI upscaling, on the default path. The models (BiRefNet for segmentation, super-resolution for upscaling) need a real GPU to finish in seconds. The in-browser fallbacks work but are slower and produce a visibly cruder result on hair, fur, and fine edges.
  • AVIF encoding, on conversion. The in-browser AVIF encoder is slow on some devices, so AVIF output routes one request to the compression Worker, with a main-thread browser encode as the fallback.

The cost we accept for being server-side on those paths is one round-trip per operation. The cost we avoid by staying client-side everywhere else is the round-trip fee on the parts of the workflow that iterate fastest.

The pipeline, step by step

1. You select a file

Through the file picker, drag-and-drop, or paste, the browser hands JavaScript a File object. JavaScript reads the bytes using FileReader or Blob.arrayBuffer(). At no point in this step is the file sent over the network, regardless of which tool you’re using.

2. The browser decodes the image

Modern browsers natively decode JPG, PNG, WebP, GIF, and AVIF. 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, this is where the paths diverge

  • Browser-only tools (cropping, resizing, format conversion to PNG/JPEG/WebP, the compress preview). A Canvas 2D pixel transform or a WebAssembly codec re-encodes the bitmap locally. The result is ready without any upload. Cropper.js handles the interactive crop frame for the crop tools, and canvas.toBlob handles the preview re-encode. Entirely in your browser.
  • Compress, download. When you tap “Download”, the image is sent once to api.roundcut.com.br (a Fastify service running on a VPS in Germany operated by Hostinger, Node 24 + sharp 0.34 + libvips 8.17, the same C libraries Squoosh uses on its server path). It is re-encoded with the same parameters you set in the preview, and the bytes are streamed back to your browser. The service keeps a tenant-isolated, content-addressed cache (a hash of the input bytes + parameters) capped at 500 MB so that re-downloading the same image with the same settings replays the cached bytes, the cache is not indexed by you, IP, or filename. If the service is unreachable, the tool falls back to the in-browser preview blob.
  • Remove Background, default cloud path. The image is uploaded once to a Cloudflare Worker, staged in a private R2 bucket, processed by Cloudflare’s cf.image.segment transformation which runs the BiRefNet model on Cloudflare’s edge GPUs, and the cutout is streamed back. The staged R2 object is deleted within one hour by an R2 lifecycle rule, regardless of outcome. A typical photo finishes in 1-3 seconds. Daily per-IP and 5 MB upload caps keep the free tier sustainable.
  • Other cloud-backed tools (AI upscaling, AVIF encoding, multi-image PDF) follow the same shape: one request to named infrastructure (a cloud image API for super-resolution, the compression Worker for AVIF encode, our VPS service for multi-image PDF), result streamed back, and a transparent in-browser fallback if that request fails.
  • WebAssembly fallback. If the relevant cloud path is unreachable (your network drops, you’re behind a strict firewall, the daily quota is full, or the file exceeds the cloud cap), the tool transparently switches to a local model or codec running in your browser, for example the ISNet background-removal model via ONNX Runtime Web with WebAssembly. The first run downloads the model and is slower, subsequent runs are faster. No upload on these fallback paths, you can verify it in DevTools.

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. The file appears on your disk.

How to verify it yourself

Pick whichever you prefer:

Method 1. Watch the Network tab

  1. Open RoundCut in a fresh tab and open DevTools → Network.
  2. Use a browser-only tool, Circle Crop or the Compress preview slider. You will see requests for HTML/CSS/JS/fonts only, plus the relevant WebAssembly modules on first use. No request will carry your image bytes.
  3. Now use a server-touching tool, Compress → Download or Remove Background. You will see exactly one POST carrying your image, and one response coming back with the result. Hover any request to see size and timing.

The “Initiator” column tells you which script triggered each request, and the “Type” column tells you what was sent. We don’t hide either.

Method 2. Use the tools offline

  1. Load any RoundCut tool page. Use Remove Background once on a small image so the in-browser ISNet model is cached.
  2. Open DevTools → Network → tick Offline (or turn off Wi-Fi).
  3. Reload the page, the static assets are cached, so it still loads.
  4. Try the tools:
    • Browser-only tools (Circle Crop, resize, the Compress preview) keep working, they never needed the network.
    • Compress Download falls back to the in-browser preview blob (slightly less efficient encode, but functional).
    • Remove Background falls back to the ISNet WebAssembly model and works without any outbound request.

If the tools worked offline (cloud-backed ones slightly degraded, browser-only ones identical), by definition no server saw your image.

What we do see, and what we don’t

On the client-side paths, we see nothing about your image. There is no request to look at, no cache to store it in, no log line to grep.

On the server-side paths:

  • The compression and PDF service sees the image bytes for the duration of the encode (typically a few hundred milliseconds), keeps a content-addressed cache entry for cache TTL, and that’s it. The cache is not indexed by user, IP, filename, or any identifier we could use to find “your” images. We do not log image content. The encode service is shared across the same two tenants v1 served before cutover, with per-tenant CORS, rate limits, and HMAC-signed canonical URLs.
  • Remove Background and the other AI paths see the image for the duration of the staging upload and the model call (typically a few seconds), after which the staged copy is deleted by an R2 lifecycle rule. The BiRefNet model runs inside Cloudflare’s own infrastructure, not on a remove.bg / fal.ai / Replicate-style external API.

On every path, our analytics provider (Cloudflare Web Analytics) records aggregate page-view data. URL, country, browser family, Core Web Vitals. No cookies, no persistent identifiers, nothing tied to a person.

For tools that download a WebAssembly module on first use (the HEIC decoder, the ISNet ONNX 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:

  • 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.
  • canvas.toBlob / <canvas>. JPEG, PNG, WebP, AVIF (browser-supported) encoding in the browser-only tools, and all of the crop and resize work.
  • Cropper.js, the crop-rectangle interaction layer.
  • ONNX Runtime Web, runs the ISNet WebAssembly fallback for Remove Background.
  • Cloudflare Pages, hosts the static build, serves it from the edge.
  • Cloudflare Workers + R2 + cf.image.segment (BiRefNet), the default Remove Background pipeline.
  • Fastify + sharp 0.34 + libvips 8.17 on Node 24, the compression and PDF service at api.roundcut.com.br, on a Hostinger VPS in Germany.
  • 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 requirements are JavaScript (for any tool) and a network connection (only when using a cloud-backed tool on its default path, the browser-only tools run fully offline after the first page load).

Questions

Anything we didn’t cover? Email support@roundcut.app. Technical questions welcome.