Modern browsers can decode, transform, and export common image formats locally. That means some tools can work without sending the original image to a backend at all.
If the file does not need to leave the device, you remove an entire category of questions: Where is the file stored? For how long? Is it logged? Is it copied to object storage? Is a third-party processor involved? Is cleanup actually happening?
Client-side processing does not magically make an application secure, but it can reduce the amount of sensitive data that needs to cross the network.
For personal photos, unreleased marketing assets, client work, screenshots, and internal images, that matters. Less upload latency
If your backend is doing CPU-heavy conversion for every free user, infrastructure cost scales directly with usage.
Moving suitable work to the client can reduce: CPU usage temporary storage bandwidth queue pressure
This is especially interesting for free utility tools where the server cost of a single action can be larger than the revenue generated by that user. Better offline potential
A browser tool that does not depend on a processing API can sometimes continue working even when connectivity is limited, depending on how the app itself is delivered and cached.
Typical building blocks include: File Blob FileReader createImageBitmap() OffscreenCanvas Web Workers
This is intentionally minimal, but the important idea is that the image can be decoded and re-encoded without a traditional upload-processing-download cycle.
You have to think about: memory usage large dimensions EXIF orientation transparent images browser support output quality cancellation progress reporting multiple files UI responsiveness
If a user drops 200 high-resolution photos into the browser and you decode everything simultaneously, you can easily destroy the tab.
There are many cases where a backend is appropriate or required: unsupported codecs extremely large files expensive AI models server-side persistence shared team workflows centralized processing rules conversions that require native libraries jobs that must continue after the tab closes
Once basic image conversion can happen locally, the product can make a stronger promise:
That was one of the design goals behind the basic image workflows I am building in BatchSet.
I am mentioning it because it is the real product where I have been exploring this architecture, not because every transformation inside every application should be client-side.
Before adding another API endpoint, queue, storage bucket, and cleanup job, ask one question:
Sometimes the browser is already powerful enough to do the job closer to the user.