Crop

Circle crop image Crop image

Optimize

Compress image Remove background Upscale image

Modify

Resize image

Convert

Other

Convert 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: 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 (the catalog keeps growing). 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 download (server-touching)One round-trip to our service at api.araluma.com (sharp plus libvips on a VPS in Germany), with a browser fallback.
Remove Background (server-touching)One round-trip to a Cloudflare Worker running BiRefNet on edge GPUs, with a WebAssembly fallback in your browser.

The cropping, resizing, PDF, and format-conversion tools (apart from the AVIF-output path) sit on the browser-only side. Compression download, background removal, AI upscaling, and AVIF-output conversions sit on the server-touching side, each with a local fallback.

You can verify the browser-only claims in about 30 seconds: open DevTools, go to the Network panel, clear the log, then use any browser-only tool. 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 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 in quality and speed on the encode and AI steps). Neither extreme wins everywhere.

We chose client-side wherever browsers are already excellent. The <canvas> element handles cropping, rotating, resizing, and the lossy preview encode in JPG or WebP, and modern browsers decode every common format natively. We chose server-side only for the few steps where the browser still measurably loses:

  • Compression, on the final download. Server-side sharp plus libvips produces files 10 to 15% smaller byte-for-byte than browser encoders at the same visual quality, and exposes AVIF speed and chroma tuning the browser doesn’t. The slider and preview still run 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 image segmentation runs (the same architecture as remove.bg) needs a real GPU to finish in a second or two. The in-browser fallback (ISNet via ONNX Runtime plus WebAssembly) works, but takes far longer and produces a visibly cruder cutout on hair, fur, and fine edges.
  • AI upscaling, on the default path. Cloud super-resolution recovers detail that a browser-side resample cannot, with a browser fallback when the service isn’t reachable.

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 that same 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, whichever 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, where the paths diverge

  • Browser-only tools (cropping, resizing, the compression preview and slider, PDF assembly, and most format conversions). These run as Canvas pixel transforms and canvas.toBlob re-encodes right on your machine. The interactive crop frame uses Cropper.js. Nothing leaves the page.
  • Compression download. When you tap “Download”, the image goes once to api.araluma.com (a Fastify service on a Hostinger VPS in Germany, Node plus sharp and libvips, the same C libraries Squoosh uses on its server path). It is re-encoded with the parameters you set in the preview, and the bytes stream back. The service keeps a tenant-isolated, content-addressed cache (a hash of the input bytes plus parameters) so re-downloading the same image with the same settings replays cached bytes. That cache is not indexed by you, your IP, or filename. If the service is unreachable, the tool falls back to the in-browser preview blob.
  • Background removal, default cloud path. The image uploads once to a Cloudflare Worker, is staged in a private R2 bucket, processed by Cloudflare’s image segmentation running the BiRefNet model on edge GPUs, and the cutout streams back. The staged object is deleted within one hour by an R2 lifecycle rule, regardless of outcome. A typical photo finishes in a second or two. Daily per-IP and upload-size caps keep the free tier sustainable.
  • Background removal, WebAssembly fallback. If the Worker is unreachable (your network drops, a strict firewall blocks it, the daily quota is full, or the file is too large for the cloud cap), the tool quietly switches to the ISNet model running locally via ONNX Runtime Web and WebAssembly. The first run downloads the model and takes longer, later runs are quicker. No upload on this path, verifiable in DevTools.
  • AI upscaling. The default path sends the image once to a cloud super-resolution service and streams the enlarged result back, with a browser-side fallback if the service can’t be reached.

4. You download the result

The output bitmap is encoded into a Blob, wrapped in an object URL, and handed to your browser’s standard file-save dialog. The file lands 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, then the Network panel.
  2. Use a browser-only tool like Circle Crop or the Compress preview slider. You will see requests for HTML, CSS, JS, and fonts only, plus the relevant WebAssembly modules on first use. No request will carry your image bytes.
  3. Now use a server-touching tool like Compress Download or Remove Background. You will see exactly one POST carrying your image to the named endpoint, and one response coming back with the result. Hover any request to read its size and timing.

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

Method 2. Use the tools offline

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

If those tools worked offline (some degraded, the browser-only ones identical), then by definition no server saw your image.

What we do see, and what we don’t

On the browser-only 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-touching paths:

  • Compress Download sees the image bytes for the duration of the encode (usually a few hundred milliseconds), keeps a content-addressed cache entry for its 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 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 a second or two), after which the staged copy is deleted by the R2 lifecycle rule. We never hand your bytes to a third-party model provider. The BiRefNet model runs inside Cloudflare’s own infrastructure, not on an external remove.bg, fal.ai, or Replicate-style API.
  • AI upscaling sees the image for the duration of the super-resolution call, returns the result, and retains nothing tied to you.

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 a CSS file fetched. The module itself carries 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 and <canvas>, the JPEG, PNG, WebP, and AVIF encoding for the browser-side tools and previews.
  • Cropper.js, the crop-rectangle interaction layer.
  • ONNX Runtime Web, which runs the ISNet WebAssembly fallback for Remove Background.
  • Cloudflare hosts the static build and serves it from the edge, and runs the Workers, R2, and image-segmentation pipeline (BiRefNet) behind the default Remove Background path.
  • Fastify with sharp and libvips on Node, 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 (for example showSaveFilePicker or OffscreenCanvas), we use it, and 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 server-touching path, the browser-only tools run fully offline after the first page load).

Questions

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