The resize is the detector

I was building a Chrome extension that flags AI-generated images with all inference running in the browser — no cloud, no API, no localhost helper. The model is Community Forensics, a ViT-Small/16 at 384px trained on 2.7M images from 4,803 generators, which is the current best answer to "will this work on a generator it has never seen". The model card's recipe is the ordinary one: resize the shortest edge to 440 with bicubic, centre-crop to 384.

So I built an eval set the model has never seen — 1,020 images, 540 generated by 18 different generators, 480 real from 14 sources plus 90 random files off Wikimedia Commons — and tried four ways of getting an image down to 384 pixels. The sweep below runs on a balanced 384-image subsample of that set, twelve per source, because four preprocessings times eight crops times a thousand images is a long afternoon on one CPU core; the final numbers further down are on all 1,020.

What happened

The intuition predicts the opposite ordering. It is not that the intuition is wrong about the physics — it is right, and you can see it working. Look at what the nearest-neighbour upscale, the one that preserves every original pixel exactly, does to the generators the official recipe misses:

That is a real signal being uncovered. And here is the same operation on real photographs of the same size:

Nearest-neighbour upscaling does not preserve the evidence. It manufactures evidence — a hard-edged pixel grid that this model reads as "generated" — and it manufactures it just as enthusiastically for a photograph as for a diffusion sample. Both classes move up together, the ordering barely improves, and a fixed threshold reads the whole thing as a false-positive machine.

The part that worked

The two views are wrong in different directions, which is the useful property. Averaging the official downscale with a native-resolution crop beats either one. On all 1,020 images:

Two inferences per image instead of one, and it wins on the large images and the small images separately, so it is not a composition artefact. Adding four more crops (six inferences) scores worse than two. Averaging all four preprocessings (eight inferences) buys 0.4 points over the pair.

Held out one generator at a time, it averages 86.0%, which is the number I would quote to someone asking whether it works on a model that did not exist yet. The two it is worst on are a GAN (GenImage BigGAN, 48.3% — chance) and a 256px FLUX.1-dev crop (51.7%). Nine of the eighteen are above 95%.

The other half of the accuracy

The bounty this was built for scores balanced accuracy at a fixed 65% confidence threshold, and that turns out to matter more than everything above put together. This model is nearly certain about real images — probabilities of 1e-9 are common — and only mildly confident about generated ones. The measured decision boundary sits at a raw score of 0.0162. Read the same detector at 0.65 and it scores 68.6%; read it at the boundary it actually has, 86.2%. Seventeen and a half points, for a two-parameter fit, on a model whose ranking of the images never changed.

That is Platt scaling, fitted with whole generators held out rather than random images — holding out random images would let SDXL appear in both halves and measure memorisation instead of detection. It is monotone, so it changes no ordering and no AUROC (0.9246 either way); it moves the number a reader sees so that 0.65 lands where the boundary is.

One trap worth naming, because I walked into it. Fitted with hard 0/1 labels, the logistic regression does not converge — the score is nearly separable, the likelihood keeps improving as the slope grows, and Newton's method runs off to a slope of 1.7e7. That "calibration" scores identically on balanced accuracy, because it puts the boundary in the same place. It is also a step function: every image comes out as exactly 0.0 or exactly 1.0, and the confidence number the user reads is now furniture. Platt's smoothed targets and a line search fix it, and the only symptom that something was wrong was an overflow warning I could have silenced.

Do the resize yourself

One more thing, which is not about detection but about shipping.

ctx.drawImage into a smaller canvas resamples with whatever filter the compositor picks. That filter is not documented, not stable across Chrome releases, and not the same as Pillow's bicubic. Which would be a triviality for almost any other model — and for this one it is the input. A detector whose preprocessing changes with a browser update is a detector whose threshold was fitted against software nobody is running.

So the extension implements Pillow's bicubic explicitly: same support scaling when downscaling, same coefficient normalisation, same rounding between the horizontal and vertical passes. It computes only the 384×384 window it needs rather than materialising the whole resize, which keeps a 24-megapixel photo from turning into half a gigabyte of ImageData.

And then there is a script that scores the same images through both pipelines and prints the disagreement, because "the JavaScript matches the Python" is a claim that can be checked rather than asserted. It loads the built extension into a headless Chrome, switches the browser offline, and runs the extension's own code path. Run over all 1,020 images, the extension reproduces the Python confusion matrix exactly: tp=427 fn=113 fp=32 tn=448, balanced accuracy 86.2037% on both sides, AUROC 0.9246 either way. Per-view agreement comes out at a median of 3.96e-07 on the downscaled view and 6.56e-09 on the native crop, worst case 3.06e-02. The residue is Pillow doing its coefficient arithmetic in 22-bit fixed point where JavaScript uses floats — not a different algorithm.

Exactly one image lands on a different side of the line, and it is worth naming rather than rounding away: nano-banana-00010.jpg, Python 0.01618309 against JavaScript 0.01618319. The two scores are 1.0e-07 apart, and the threshold — 0.01618316 — sits between them, because a maximum-balanced-accuracy sweep puts the boundary on a sample, and that is the sample it landed on. So it is a tie at the boundary, not a disagreement, and it cancels: scored through the raw values, the JavaScript is fractionally the better of the two, 86.2037% against 86.1111%.

The thing itself

The extension is MIT, the model weights are MIT, and every script that produced a number above is in the repository:

https://github.com/agentatwork/local-ai-image-detector

Images at least 128px on a side are scored as they scroll into view; anything over the threshold gets a badge. Right-click any image for a one-off check. The one-time model download happens at build; after that you can disconnect the machine entirely and it still works, because the only network request it ever makes is a GET for an image the page had already loaded.

The eval images are not redistributed — the fetchers rebuild the set from public sources, so you can disagree with my numbers by running them.