Why image tools should run in your browser

Search for "compress image online" and almost every result works the same way. You pick a photo, the page uploads it to a server, the server shrinks it, and you download the result. It works, and it also means a copy of your photo has left your device.

There is another way to build the same tool. The page can do the work itself, inside your browser, and never send the file anywhere. This guide explains what that changes and how to tell the two kinds of tool apart.

What an upload tool does with your file (link to section)

When a tool uploads your image, three things happen that you do not see.

1. The file travels. It crosses the network to a server you know nothing about, often in another country.
2. The file is stored, at least for a while. Many services say they delete files after an hour or a day. That is a promise, not something you can check.
3. The file is processed by someone else's software. Whoever runs the server can log it, scan it or keep it.

For a picture of a cat that is a small risk. For a passport scan, a photo of a child, a screenshot of a bank page or an ID card, it is a bigger one.

What your photo carries besides pixels (link to section)

A photo from a phone is more than an image. It usually includes EXIF metadata: the camera model, the date and time, and often the GPS position where you took it.

The amount is small. A 1.4 MB test photo with a GPS position added carries just 364 bytes of EXIF, and those bytes include the coordinates.

If you upload that file to a server, the server receives the metadata as well. With a browser-only tool the file and its metadata stay on your device.

The cost of uploading, in seconds (link to section)

Privacy is one cost. Time is the other. This is plain arithmetic, so you can redo it with your own numbers.

Then add the same time again to download the result, plus the wait while the server queues your job. On a train or a patchy mobile connection that is the difference between a tool you use and a tool you give up on. A local tool skips both trips.

How a browser can do the work itself (link to section)

Three browser features make this possible.

• Web Workers run code on a separate thread, so a heavy job does not freeze the page.
• WebAssembly runs compiled code at close to native speed. The same encoders that servers use, such as MozJPEG for JPEG and libwebp for WebP, can be compiled to WebAssembly and shipped to your browser.
• The File API and canvas let a page read the file you picked and draw, scale or crop it, all in memory.

When the work is done, the page builds a download link from the result in memory. Closing the tab discards it.

// Read the file you picked. It never leaves the page.
const file = input.files[0]
const bitmap = await createImageBitmap(file)
 
// Draw it at half size on an offscreen canvas.
const canvas = new OffscreenCanvas(bitmap.width / 2, bitmap.height / 2)
canvas.getContext("2d")?.drawImage(bitmap, 0, 0, canvas.width, canvas.height)
 
// Encode it and offer a normal download.
const blob = await canvas.convertToBlob({ type: "image/webp", quality: 0.8 })
const url = URL.createObjectURL(blob)

Nothing in that snippet touches the network.

How to tell which kind of tool you are using (link to section)

You do not have to trust a claim on a landing page. You can check.

When uploading still makes sense (link to section)

Browser tools are not always the right choice. A server can use more memory and more cores than your phone, so it suits very large batches and jobs like video transcoding. If you are happy to hand the files over, an upload service can be fine. The point is that for everyday image jobs, such as shrinking a photo, changing its format or removing its location, you should not have to.

What to do next (link to section)

Start with the job you do most. Compress an image, convert a HEIC photo to JPG, or remove EXIF data from something you are about to share.