Why the detector runs in your browser | Best AI Image Detector

So your images never leave your device. The model downloads once and runs on your machine, which removes the upload, the server cost and the data processing relationship at the same time.

What the architecture actually is

A vision transformer, converted to ONNX and compressed to about 40 MB, split into two parts so each stays under the file size limit of the hosting platform. It is reassembled in the browser and its checksum verified before anything runs.

Inference happens through WebAssembly, which lets a compiled runtime execute at close to native speed inside a browser tab. The runtime itself is a compressed WASM binary loaded alongside the weights.

Nothing about this is exotic any more. What was a research demonstration in 2021 is now a normal way to ship a model, and the browsers did most of the work.

What it buys

Property	In the browser	On a server
Image leaves your device	No impossible	Yes required
Cost per check	Yes zero	No real compute
Data processing agreement needed	No	Yes
Works with no network after load	Yes	No
Model can be kept private	No it is downloaded	Yes
First check is instant	No model downloads once	Yes

The same product, built two ways. The differences are architectural rather than policy choices.

The first row is the reason the rest exist. Because there is no upload endpoint, there is no bucket of other people's photographs, no retention policy to write, no breach to disclose and nothing to hand over on request.

The second row is why it can be free without a usage meter. A check costs nothing to serve, so there is no per-image cost to recover, which changes what the pricing has to look like.

What it costs

Three real trade-offs, stated plainly, because a page that only lists advantages is advertising.

The first check is slow. Forty megabytes has to arrive before anything happens. On a fast connection that is a few seconds; on a poor one it is longer. Subsequent checks reuse the cached model and start immediately.
Old devices struggle. Inference needs memory and processing that a five-year-old phone may not comfortably have. A server would not care what device you are holding.
The model is public. Anything downloaded to a browser can be kept. A server-side model can be proprietary; this one cannot, and the weights are an open research checkpoint anyway.

The third point is worth being direct about. Shipping a model to the client means giving it away. That is an acceptable trade here because the weights are already published, and the work that makes the tool useful is the calibration, the tiling and the interpretation built around them.

The engineering problems worth knowing about

Splitting a large file

Static hosting platforms cap individual file sizes. A 40 MB model exceeded the limit, so it ships as two deterministic parts that are reassembled in the browser and checked against a manifest hash before use. A corrupted or substituted part fails loudly rather than silently producing wrong scores.

Loading nothing until it is needed

The model, the runtime and the credential reader are not fetched on page load. They arrive on first engagement, so somebody reading an article never downloads any of it. That keeps the pages fast for the large majority of visitors who never run a check.

Decoding awkward formats

HEIC from iPhones, AVIF, TIFF and JPEG XL all need decoding before scoring. Browsers now handle most of these natively, which removes what used to be the largest piece of client-side work in a tool like this.

When this architecture is the wrong choice

It is not universally better. A server makes more sense when the model is proprietary and worth protecting, when it is too large to ship, when you need results in a backend pipeline rather than in front of a person, or when you need a guaranteed response time regardless of the device.

For a tool somebody opens to check one suspicious picture, none of those apply, and the privacy property is worth more than everything a server would add.

What this rules out

Choosing the client has consequences beyond privacy, and some of them are limitations worth naming rather than features.

There is no history. A result exists only in the tab that produced it, so nothing can be looked up later unless it was exported. That is the direct cost of not having an account, and it is the single most requested thing that the architecture makes awkward.

There is no shared state. Two people cannot see the same queue, and a team cannot review each other’s checks. A shared link carries a single result, which covers a conversation and not a workflow.

There is no API. Anything running in a browser tab cannot be called from a backend pipeline, which rules out the highest-volume uses entirely. Those are real gaps, and the honest position is that they are the price of the property that matters more.

Questions people ask

Is my image really not uploaded?

Yes, and you do not have to take that on trust. Open the network tab in developer tools and run a check. You will see the model and runtime download, and no request carrying your file. It is one of the few privacy claims a user can verify directly in about thirty seconds.

Why is the model so large?

It is a vision transformer with millions of parameters, compressed as far as it goes without losing accuracy. Smaller models exist and perform noticeably worse, particularly on the compressed, cropped images people actually check. Forty megabytes is the price of the accuracy.

Does it work offline?

After the first load, largely yes. Once the model is cached the scoring runs with no network at all. The one part that needs a connection is fetching an image from a pasted URL, and checking a local file works without one.

Will it drain my phone battery?

A single check is a few seconds of processing, comparable to loading a heavy web page. Running a batch of twenty-five is more noticeable. It is not something you would leave running, and it is not a meaningful cost for occasional use.

Could you not use WebGPU to make it faster?

For devices that support it, yes, and support is still uneven enough that a WASM path has to exist regardless. Adding a second execution path doubles the surface where results could diverge between users, which is a real cost against a speed gain most people would not notice.

Does the browser send anything about my image at all?

No. There is no telemetry on file names, dimensions or scores, because the result never exists anywhere except in your tab. That is a consequence of the architecture rather than a setting, which is the part worth understanding.