Browser-local image tools: how to check the upload boundary

Fang Ji — Fri, 06 Nov 2026 05:34:44 +0000

Browser-local image tools: how to check the upload boundary

This guide comes from the ImgIng project. It explains how to evaluate an image tool's processing path; it is not an independent security audit or a comparison of compression performance.

A browser interface does not tell you where a file is processed. A web app might run a codec on your device, send the source to a service, or combine both paths. The useful question is more specific than “is this website private?”: what does this selected operation send, receive, and save?

Separate the operation from the product name

ImgIng's published documentation describes common image-processing routes as local to the browser. It also documents specialist-server exceptions. Reading an existing HEIC photo is a different operation from exporting a new HEIC file, for example. A local compression workflow does not establish that every conversion offered by the same site is local.

Selected task	Published processing boundary	What to check before using it
Common-format image compression and supported local exports	Described by ImgIng as browser-local	The actual input, chosen output, and notice in that workflow
HEIC writing, TIFF, JPEG 2000, or exporting images to PDF	May use a labelled specialist server	Whether this operation uploads material and whether that fits your requirements
Compressing an existing PDF	Described as local; different from creating a PDF from images	The PDF's supported features and the saved result
HTML to PDF	Has a server-side rendering path	The conversion notice rather than a general local-processing claim

These are documented boundaries, not measurements performed for this post. Check the current tool notice because file type, output choice, and product changes can affect the route.

A download is not the same event as an upload

A local application still needs its page, scripts, and other assets. Some workflows also download a codec or a machine-learning model before processing can start. Network activity alone therefore does not prove that the source image left the device. Conversely, finding one local worker does not prove that another part of the workflow never sends data.

Squoosh provides another useful distinction: its official README describes local compression, while separately disclosing analytics. Local image processing and the absence of all telemetry are different claims. Evaluate each requirement separately.

Inspect a small, permission-cleared example

Choose a non-sensitive image you own or are allowed to use. Keep an unchanged original.
Open the browser's Network panel before loading the workflow. Record the browser version, page, date, and selected task.
Run that one operation. Distinguish document, script, codec, and model downloads from requests carrying file or image content. Inspect payloads where the browser makes them available.
Repeat after assets are cached, recording the difference. Do not turn one apparently quiet run into a claim covering every format or feature.
Save and reopen the output. Confirm dimensions, format, transparency, text legibility, and the details that matter to the intended use.

Browser inspection can provide observations for a particular run; it is not a complete security audit. If your organization restricts uploads, follow those handling rules and verify the selected route before using confidential material.

Record output quality separately

For compression comparisons, retain the input and output files, actual byte sizes, dimensions, format, exposed quality settings, errors, and unsupported cases. Compare equivalent tasks: PNG-to-PNG optimization and converting PNG to WebP answer different questions. Smaller files can still lose detail or behave differently in the destination workflow.

The aim is a reproducible decision about a concrete job, with the data path and output quality evaluated independently. You can explore ImgIng using a permission-cleared example and the current operation notices.

Sources

Sources checked on November 6, 2026. Product statements are attributed to their publishers. No new compression benchmark, file-handling test, or security-audit result is presented here.

I built an image toolbox that keeps common processing inside the browser

Fang Ji — Tue, 25 Aug 2026 03:50:40 +0000

I work with product images every day. The usual workflow was surprisingly annoying: one site for compression, another for format conversion, another for background removal, and another for animated images. Most of them required uploading the original file.

So I built Imging as a local-first browser tool. Common image work stays on the device: JPG, PNG, WebP, AVIF and HEIC conversion, compression, background removal, and GIF/APNG/animated WebP editing. Larger codecs and models load only when a feature needs them.

The main engineering lesson was that “runs in the browser” is not one capability. Decoding, canvas processing, encoding, WebGPU inference, WASM fallback, memory limits and file saving all fail independently. I now test each capability instead of assuming support from the browser name.

Background removal prefers WebGPU and falls back to WASM. Animated images go through a frame pipeline so timing and loop information can be kept while frames are edited or recompressed. PDF compression rewrites the document structure instead of turning every page into a large bitmap.

There are still honest limits. Some uncommon formats cannot be handled completely in the browser, mobile memory is tight for large animations, and HEIC files are not always consistent. The tool reports those cases instead of pretending every operation is local.

Imging is free to use without an account or watermark:

https://imging.cn/en/

I used AI-assisted coding during development, but the capability checks, processing boundaries and validation cases came from the actual product-image workflow.

DEV Community: Fang Ji

Browser-local image tools: how to check the upload boundary