Crop

Circle Crop Crop Image

Optimize

Compress Image AI Image Upscaler Remove Background

Modify

Resize Image

Convert

Other

JPG to PDF

How Araluma works

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

The short answer

Araluma uses a hybrid architecture: two tools run entirely in your browser with zero upload, and two tools route a single network request through our own infrastructure when the browser cannot match the quality. We tell you which path you’re on, in every tool and on this page.

ToolWhere the work happens
Circle Crop100% in your browser, Canvas API. No upload, works offline.
Compress preview (slider + format comparison)100% in your browser, canvas.toBlob. No upload.
Compress final downloadOne round-trip to our service at api.araluma.com (Fastify + sharp + libvips on a VPS in Germany).
Remove BackgroundOne 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.

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

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, 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, on the default path. The BiRefNet model that Cloudflare’s cf.image.segment runs (same architecture as remove.bg) needs a real GPU to finish in 1-3 seconds. The in-browser fallback (ISNet via ONNX Runtime + WebAssembly) works, takes 20-40 seconds on first run plus 2-10 seconds afterward, and produces a visibly cruder cutout on hair, fur, and fine edges.

The cost we accept for being server-side on those two paths is one round-trip per operation. The cost we avoid by staying client-side everywhere else (Circle Crop, the Compress preview) 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

  • 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. Entirely in your browser.
  • Compress — preview and slider. Re-encodes JPG, PNG, WebP, or AVIF using canvas.toBlob so the side-by-side preview updates as you move the quality slider. Entirely in your browser. No upload yet.
  • Compress — Download. When you tap “Download”, the image is sent once to api.araluma.com (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 (araluma-bg-remover), staged in a private R2 bucket (araluma-bg-temp), 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.
  • Remove Background — WebAssembly fallback. If the Worker is unreachable (your network drops, you’re behind a strict firewall, the daily quota is full, or the file exceeds the 5 MB cloud cap), the tool transparently switches to the ISNet model running locally in your browser via ONNX Runtime Web with WebAssembly. First run downloads the ~80 MB model and takes 20-40 seconds; subsequent runs take 2-10 seconds. No upload on this path — 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 Araluma in a fresh tab and open DevTools → Network.
  2. Use 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 Compress → Download or Remove Background. You will see exactly one POST to api.araluma.com (Compress) or to the Remove Background Worker, 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 Araluma 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 each tool:
    • Circle Crop and 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 four tools worked offline (one slightly degraded, three 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:

  • Compress Download 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 sees the image for the duration of the staging upload and the segmentation call (typically 1-3 seconds total), after which the staged copy is deleted by the R2 lifecycle rule. We never call any third-party model provider with your bytes — 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 Compress preview, and all of Circle Crop.
  • 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 Compress download service at api.araluma.com, 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 Compress Download or the default Remove Background path — the other paths run fully offline after the first page load).

Questions

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