Two kinds of tool
Every Araluma tool belongs to one of two groups. Browser tools read, edit and save your file on your own device. Server-backed tools upload the file, process it on our servers or with an image provider, and hand the result back. The server-backed tools also carry a plan B that finishes the job in your browser when the servers cannot be reached.
| Tool | Browser only | Server-backed | Plan B when servers fail |
|---|---|---|---|
| Circle Crop, Crop Image, Resize | Always | Never | Not needed |
| Convert (one file, output PNG, JPG or WebP) | Yes | No | Not needed |
| Convert (AVIF output, or two or more files) | No | Yes | Browser encoder |
| JPG to PDF (one image) | Yes | No | Not needed |
| JPG to PDF (two or more images) | No | Yes | Browser assembly |
| Compress | Only SVG and very large batches | Yes | Browser compression |
| Background Remover | No | Yes, Cloudflare first, ImageKit second | AI model running in your browser |
| Upscale | No | Yes, Cloudflare first, ImageKit second | Browser resampling |
One more case applies to every tool: creating a share link, or saving a result to Dropbox, stores the result file for about two hours so the link can be opened.
Why not do everything in the browser?
Browsers are excellent at geometry. Cutting, rotating, scaling and saving an image in the common formats takes a fraction of a second on the device, with no waiting for a network, so those tools never leave it.
Other jobs still go better on a server:
- Compression. Server encoders built on libvips squeeze noticeably smaller files than the encoders built into browsers at the same visual quality, and they expose AVIF settings that browsers do not.
- AVIF output. Encoding AVIF in a browser is slow and memory hungry on phones, so AVIF conversions use the same server.
- Batches and multi-page PDFs. A queue of dozens of pictures would stall a phone. The server processes them together and returns a single ZIP or PDF.
- Background removal and upscaling. Both use AI models that need a GPU to answer in seconds. The browser plan B works, but it is slower and its edges are rougher on hair and fur.
What happens to a file, step by step
- You choose a file. Picking, dragging or pasting gives the page a local reference to the file. Nothing is sent at this point.
- The browser opens it. JPG, PNG, WebP, GIF and AVIF are decoded natively. HEIC photos from iPhones are decoded by a small module that runs in the page.
- The work happens. Browser tools edit the pixels on a canvas and encode the result right there. Server-backed tools upload the file over HTTPS to temporary Cloudflare R2 storage or straight to a Cloudflare Worker, and the job runs on our server in São Paulo (compression, conversion, PDF) or in Cloudflare’s or ImageKit’s image services (background removal, upscaling). Compress may begin uploading a few seconds after you add files, so the result is ready when you press the button.
- You get the result. The finished file is offered to your browser’s normal download. Results produced on the server sit in temporary storage for about two hours (the Compress download screen can delete them at once) and are then removed automatically.
The privacy policy has the complete retention table and the list of providers.
Check it in your own browser
Network panel. Open the developer tools (F12 on most desktop browsers), select the Network tab and clear it. Run Circle Crop, Crop Image or Resize: you will see page assets being loaded and no request that carries your picture. Then run Compress or Background Remover: an upload request appears, followed by the download of the result.
Offline test. Load a browser tool, switch on airplane mode or tick “Offline” in the Network tab, and use it again. It keeps working, because it never needed the network. Server-backed tools will switch to their plan B instead, which is also a way to see where each step runs.
What we can and cannot see
For browser tools we receive nothing about your picture, because no request carries it.
For server-backed tools the file exists on our infrastructure only while the job runs and for the retention periods in the privacy policy. There are no accounts, so an uploaded file is not tied to a name or profile. We do not browse uploaded files and do not use them to train models.
On every page we record anonymous usage events (tool, step, timing, errors, country, device type) to find bugs and slow spots. We set no cross-site tracking cookie ourselves. The advertising cookies Google uses on tool pages are described, with the ways to refuse them, in the privacy policy. When an AI model or decoder is downloaded to your browser, our hosting sees that the file was requested, just as it sees a stylesheet requested, and learns nothing about your image.
What it is built with
- Astro, which renders every page as plain HTML and adds JavaScript only where a tool needs it.
- Plain CSS with design tokens, no CSS framework.
- Canvas and WebAssembly codecs for the tools that run in the browser.
- ONNX Runtime Web, which runs the background-removal model on your device when the cloud route is unavailable.
- Cloudflare for hosting, Workers, R2 storage and the image models behind background removal and upscaling.
- A Node.js service with sharp and libvips on a Hostinger server in São Paulo, Brazil, for compression, conversion and PDF jobs.
Supported browsers
The tools work on the current and the previous release of Chrome, Edge, Firefox and Safari, on computers and on phones. Where a browser offers a newer capability, the tool uses it, and where it does not, an older method takes over, so no browser is turned away. JavaScript is required for every tool, and a connection is required only for the server-backed ones.
More questions?
Technical questions are welcome at support@araluma.com.