DEV Community: yue xing

Don't trust "processed locally" — check it yourself in three steps

yue xing — Tue, 01 Sep 2026 02:41:25 +0000

Last term I had a batch of coursework images with faces in them, and we'd agreed they weren't leaving the group.

Everything I needed to do to them — compress, convert — pointed at some online tool whose landing page said "secure" and "never stored." I had no way to check that. Then someone showed me the Network tab.

First, be clear about what you're checking

"Upload" means your file went from your machine to their server. The direction is outbound.

There's one thing that gets confused with it constantly: the page downloading something to your browser. Codecs for certain formats, or AI models, get pulled down to your browser and run there. The first time you use one of those features you'll see a request anywhere from tens of KB to hundreds of MB. That's the opposite direction.

I got this wrong on my first attempt — saw a chunky request, assumed my image had been shipped off, and only on a closer look noticed it was a .wasm file fetched with GET.

This is a skill worth having once and keeping: applying for internships, handling ID photos before a job application, converting a medical form. Same move every time.

Step 1: open the Network tab and clear it

F12, or Option + Command + I on a Mac. Switch to Network.

Two things to set up:

Tick Preserve log, so a page navigation doesn't wipe your evidence
Hit 🚫 Clear and start from an empty list

Step 2: process an image and watch the list

Do the normal thing: pick your file, adjust settings, run it, download the result.

Two columns carry the answer:

Method. Uploading a file is almost always POST (occasionally PUT). If nothing POSTs across the whole operation, nothing was uploaded.
Payload. If there is a POST, open it. Either you can see your filename and a wall of binary in there, or you can't. It's not subtle.

Glance at the preview image's source too. Locally-processed tools usually show blob: URLs — that's an object living in browser memory, which never crossed the network.

Step 3: separate downloads from uploads

If you do see something substantial, three tests:

	Upload	Runtime / model download
Method	POST / PUT	GET
Filename	yours, or a random token	`.wasm`, `.onnx`, `.bin`
When	every single image	usually just the first use of a feature

Method is the reliable one. GET fetches something in; POST sends something out.

What I got when I actually ran it

I did this on ImgIng's animation workshop (imging.ai), because I had a pile of GIFs to compress anyway.

Six animation files, 120×120 up to 720×405, largest 2.62 MB
Imported, compressed and exported each of them, a dozen-plus rounds
Result: zero POST requests across the whole session
Preview URLs were blob:

One thing worth repeating, because it's the honest version: this tool states its own boundary in the interface — common formats run in the browser, but a few professional formats (HEIC writing, TIFF among them) are explicitly marked as server-side, with a differently coloured chip. So "nothing uploaded" holds for the operations I actually performed. You verified your session, not the website.

That's the real takeaway. Verification is scoped to an operation, not to a domain. Different feature, different format, look again.

Three things that trip people up

Analytics POSTs don't count. Plenty of sites fire a few hundred bytes of telemetry. Open the payload — no image content, not an upload.

No POST doesn't mean bulletproof. In principle data could go out over a WebSocket or something more creative. For ordinary web tools, watching POST covers the overwhelming majority of cases. If what you're handling is genuinely sensitive, the stronger move is to pull your network connection and see whether the tool still works — plenty of local-first tools do, and that's a much harder claim to fake.

Open the panel before you start. It only records what happens after it's open. Obvious in hindsight, annoying at the time.

That's it

No frontend knowledge required, nothing to install, about three minutes end to end. Before you drop your ID scan, your coursework data, or a signed document into a website you've never heard of, three minutes is a good trade.

Why the same image comes back 4x smaller from one tool than another

yue xing — Wed, 26 Aug 2026 12:08:31 +0000

A designer sent me two versions of the same product shot. Hers was 840 KB. Mine, after running it through a different tool, was 190 KB. Side by side on a laptop screen, I could not tell them apart.

That gap is not one tool being "better at compression." It comes from four separate decisions, and most tools make them silently. Once you know what the four are, you can tell whether a tool is optimizing or just quietly throwing away quality you did not agree to lose.

1. Format beats parameters, by a lot

This is the one people skip, and it dominates everything else.

PNG is lossless. Great for screenshots, icons, flat color, anything needing transparency. Storing photographs in it is the most common waste — photos have almost no repeating pixel patterns, so lossless has nothing to grab onto.
JPEG is lossy and built for photographs. No transparency, and hard edges on text pick up ringing artifacts.
WebP lands roughly 25–35% under JPEG at comparable quality, and it supports transparency.
AVIF goes smaller still, but encodes slowly and older software may refuse to open it.

So if tool A hands you back a WebP when you fed it a PNG, of course its output is dramatically smaller. That is not a better algorithm. That is a different event.

Before you compare two tools, check what container came back:

// drop this in the console after downloading both files
const buf = new Uint8Array(await file.arrayBuffer());
const sig = [...buf.slice(0, 12)].map(b => b.toString(16).padStart(2, '0')).join('');
// 89504e47 → PNG   ffd8ff → JPEG
// 52494646 ... 57454250 → RIFF….WEBP
console.log(sig);

If the signatures differ, the size comparison is meaningless and everything below is moot.

2. Quality 100 is not "safe," it is expensive

Every lossy encoder exposes a quality knob, usually 0–100. The reflex is to drag it to 95 or 100 and feel responsible about it.

Above roughly 85, file size climbs steeply while the visible difference collapses. A quality-100 JPEG can be more than twice the size of the same image at 85, and putting them side by side at 200% zoom, most people cannot call which is which.

The part that actually matters: the best quality point depends on what is in the picture.

Content	Workable quality	Why
Ordinary photos	~75	Losses stay below the noise floor of the image
Smooth gradients (sky, flat backdrops)	~72	Low information density to begin with
High texture (grass, fabric, grain)	~80	Detail smears into mush below this
Graphics and text (screenshots, charts)	84+	Text edges are brutally sensitive to artifacts

A tool that classifies the image first and then suggests a value is doing real work. A tool that applies one number to everything is not.

3. The most underrated move: change the dimensions

This usually beats parameter tuning outright, and almost nobody does it first.

Phone cameras happily produce 4000×3000. The place you are about to put that image — a chat thread, a doc, a web page — often renders it at 800 px wide. Every pixel beyond that is pure overhead, and size scales with area: halve the longest edge and you land near a quarter of the bytes.

So the order is: decide the display size, resize to it, then argue about quality. Tuning quality on a 4000-pixel-wide image is effort spent in the wrong place.

Rough targets that hold up in practice: 1500 px for chat, under 1200 px for in-article web images, 800 px for document figures.

4. The bytes you cannot see

A photo straight off a phone carries more than pixels:

EXIF — capture time, camera model, exposure settings, GPS coordinates
ICC profile — sometimes hundreds of KB on its own
Embedded thumbnail — a second, smaller copy of the image
Depth and HDR gain maps — newer phones write these routinely

Together these can run to tens or hundreds of KB. Some tools strip all of it and post an instant win. Others preserve everything.

There is a privacy edge to this one. EXIF GPS records where the photo was taken. Posting an original straight to the web can publish your home address alongside it. Most social platforms strip EXIF on upload — but not all of them, and files you send through cloud storage, forums, or email usually keep it intact.

// crude check: does the file still carry an EXIF block?
const head = new Uint8Array(await file.slice(0, 65536).arrayBuffer());
const hasExif = [...head].some((b, i) =>
  b === 0x45 && head[i+1] === 0x78 && head[i+2] === 0x69 && head[i+3] === 0x66); // "Exif"
console.log(hasExif ? 'metadata still present' : 'stripped');

Even lossless has room

PNG output varies between tools too, which surprises people who read "lossless" as "only one possible result."

PNG lets the encoder pick a row filter per scanline, and a good encoder tries several and keeps the best. Separately, reducing a truecolor image to a 256-color palette is technically lossy, but for icons, screenshots, and UI elements the difference is usually invisible while the file drops to roughly a third.

That palette step is where implementations diverge hardest. Same 256 colors on paper — but how the palette is chosen, and how precisely each pixel maps into it, decides whether you get clean output or banding and muddy patches.

How to catch a tool degrading your image quietly

Smaller is not automatically better. Four checks:

Did the format change? You uploaded PNG. Is the download still PNG? A silent switch to JPEG turns transparency into black or white.

Did the dimensions change? Some tools cap the longest edge by default and never mention it.

Zoom in on the failure-prone areas. Text edges, smooth gradients, dark regions. Blurry glyphs, ringed banding across a sky, blocky patches in shadows — all signs of overcompression.

Does it tell you where processing happens? On your machine, or on their server? A serious tool states this outright. To verify, open DevTools → Network, process an image, and watch what moves. You should see codecs being downloaded to you, not your image going out.

That last check is what pushed me toward ImgIng for everyday work. Common-format conversion and compression run locally in the browser with no upload request for the image itself, and the interface marks which capabilities are local versus which go server-side — HEIC writing and some professional formats still require an upload, and it says so rather than hiding it. That is a claim you can confirm in thirty seconds with the Network panel, which is worth more than any assurance in a marketing page.

The short version

When the same image comes out four times smaller somewhere else, it is usually a combination of:

Format changed — the largest single factor; confirm you are comparing like with like
Different quality target — returns collapse above 85, and the sweet spot moves with content type
Dimensions changed — the most effective and most overlooked; half the edge, a quarter of the bytes
Metadata stripped — EXIF, ICC, thumbnails; also a privacy question

Working order: size first, then format, then quality. Reversed, most of the effort goes where the returns are smallest.