How browser-based file processing works (and what it can't do)

The browser APIs that make this possible

Browser-based file processing is not new — it has been technically possible since around 2014 — but the right pieces only became reliable across all major browsers more recently. The pipeline ConvertUnlimited uses relies on four standards:

• File and Blob. When you select a file or drop one onto a page, the browser exposes it as a File object — a stream of bytes in local memory with a name and a MIME type. Nothing has crossed the network.
• Canvas. The 2D Canvas API decodes JPEG, PNG, GIF, WebP, BMP, and (on modern browsers) AVIF. You draw the image to a canvas and call canvas.toBlob('image/webp', 0.85) to re-encode it. That single function call is the whole "image converter" for supported formats.
• WebAssembly. Some formats — HEIC, AVIF encoding on older browsers, PDF parsing — aren't covered by Canvas. WebAssembly lets us ship a compiled C or Rust decoder for those formats and run it in the same browser tab. Performance is within 1.5–2× of native code; for typical image sizes the difference is measured in tens of milliseconds.
• Web Crypto. Hashing, JWT verification, base64, and similar developer tools use the browser's built-in cryptographic primitives. SHA-256 of a file is a few milliseconds even on a mid-range phone, and the implementation has been hardened by every major browser team for years.

The full pipeline, one image

If you convert a single 3000×2000 JPEG to WebP on this site, here is exactly what happens, in order:

1. You drop the file. The browser fires a drop event with a FileList containing one File.
2. The tool calls file.arrayBuffer() to get the bytes into memory. Nothing leaves the tab.
3. The bytes are wrapped in a Blob and a temporary URL is created via URL.createObjectURL(blob). The URL points at the in-memory data and is only valid in this tab.
4. An invisible <img> element loads from that URL. The browser's native JPEG decoder turns the bytes into pixels.
5. The decoded pixels are drawn onto an offscreen HTMLCanvasElement.
6. canvas.toBlob('image/webp', 0.9) re-encodes the pixels as WebP and returns a new Blob.
7. A second object URL is created and attached to a download anchor. You click it; the browser saves the new file.

At no point does the file or the resulting WebP bytes leave the tab. You can verify this by opening DevTools → Network before dropping the file: the panel stays empty during processing.

How to verify the local-only behaviour yourself

1. Open the tool page in a clean browser profile, with extensions disabled.
2. Open DevTools → Network. Tick "Preserve log" and "Disable cache."
3. Clear the log so the panel is empty.
4. Drop a sample file and run the conversion.
5. Inspect the panel. You should see no new requests during processing. Static-asset requests (CSS, fonts, analytics) may appear at page load, but the file processing itself shouldn't trigger anything.

Where this model honestly doesn't work

• Very large files. Multi-gigabyte videos, hundred-megapixel images, large PDFs with thousands of pages — the browser has to hold the working set in memory, and at some point that exceeds what the device has. The browser will either fail or fall over.
• Unsupported formats. If neither Canvas nor a JavaScript library decodes the format you have, no amount of local-first will change that. Some obscure raster formats, certain CAD files, and proprietary formats fall into this bucket.
• Batches of thousands. Browsers will process them one at a time and the page will sit idle for a long time. A desktop tool or a real backend pipeline is faster and won't tie up your browser.
• Automation and APIs. If you want to convert images from a server-side process — a CMS publish step, an image-CDN, a CI pipeline — the browser is the wrong layer entirely. Reach for libvips, sharp, ImageMagick, or a managed image service.

Why this matters

The dominant pattern for "free online file tools" is upload-based: you upload, the server processes, you download the result. That model has been normalized to the point where most people assume there is no other way. But for the tasks most people actually need — converting an image, compressing a PDF, removing metadata, formatting JSON — the browser is now powerful enough to do the work locally. Keeping the file on the device removes a category of risk (server breaches, accidental retention, ambiguous data policies) and removes a category of cost (server bandwidth, queues), which is why ConvertUnlimited can offer everything for free without a sign-up.

Frequently asked questions

Why doesn't the browser need a server to convert images?

All the work a basic format conversion needs — reading bytes, decoding into pixels, re-encoding as a different format — is exposed by browser APIs that have existed since around 2014: File for reading, Canvas for decoding and re-encoding common image formats, and Blob URLs for downloading the result. A server is needed only when the format itself is unsupported by the browser, when the work is too heavy for the device, or when batch automation is required.

Can ConvertUnlimited see my files?

For supported tools, no — there is no server-side upload endpoint in the conversion flow, and the page contains no code path that POSTs file bytes anywhere. You can verify this in DevTools by opening the Network panel before processing a file: no requests should appear during processing.

What does WebAssembly add?

Some formats — HEIC, PDF parsing, AVIF encoding on older browsers — are not handled natively by the browser. WebAssembly lets us run a compiled C or Rust decoder for those formats inside the same browser tab, without leaving the tab. It costs a one-time download of the WASM bundle when you first open the relevant tool.

Where does this model break down?

Very large files (multi-gigabyte), formats no browser library handles yet, batches of thousands of files at once, and pipelines that need server-side automation. For those, a desktop tool or a real backend is the right answer.

Try it

The ConvertUnlimited image converter is the most-used surface for this model. Drop a file, open DevTools, and watch the Network panel stay empty.