← All guides Accuracy

Every way an AI image detector can be wrong

A complete failure taxonomy: what breaks, why, and what each failure looks like when it lands in front of you. Written to be read before you trust a score.

· 8 min read · Best AI Image Detector

Four families of failure: the image was degraded, the generator was unseen, the content resembles synthetic texture, or somebody laundered it deliberately. Each produces a different wrong answer.

Family one: the image was degraded

The largest category by a wide margin. The signal a detector reads lives in fine texture, and that texture is the first thing every compression, resize and screenshot discards.

  • Repeated JPEG saves. Accuracy falls from 91.3 percent on clean originals to 84.6 percent at quality 40 on the published benchmark, and further in the wild.
  • Screenshots. A re-render at screen resolution with the original file discarded entirely.
  • Downscaling. Fewer pixels, less texture, and below about 576 pixels on the shorter side no region map at all.
  • Platform re-encoding. Every upload is at least one re-encode, and most images have been through several.
  • Aggressive cropping. A small crop of a large image loses the context the model was calibrated on.

Degradation pushes scores toward the middle in both directions: genuine photographs upward, generated images downward. A middling result on a clearly travelled file usually means the file, not the picture.

Family two: the generator was unseen

A detector recognises what it was trained on. A model released after training finished is unfamiliar territory, and unfamiliar output tends to score low rather than uncertain.

  1. 1 Generator released Nothing has seen its output
  2. 2 Blind window New output scores as real
  3. 3 Samples gathered Weeks of collection and labelling
  4. 4 Detector updated Until the next release
The blind window is structural. Retraining always follows a release rather than preceding it.

This produces confident false negatives, which are the most dangerous kind. The tool is not signalling uncertainty; it is reporting that an image looks fine because it does not resemble anything it was taught to flag.

Family three: the content resembles synthetic texture

Some genuine images are simply hard. Not because anything was done to deceive, but because the texture they contain looks like the texture generation produces.

  • Phone night mode and computational photography. Several frames merged and denoised by software, which rewrites fine detail across the whole image.
  • Heavy retouching. Skin smoothing and frequency separation rebuild texture on faces.
  • Upscaled images. Enlargement invents pixels, and invented pixels are generated pixels.
  • Illustration, 3D renders and CGI. Never photographed, so nothing about them resembles a camera capture.
  • Stock photography with heavy noise reduction. Commercially processed to look clean, which reads as synthetic.
  • Very flat images. Blank walls, clear skies and plain backgrounds carry little signal in either direction.
57 62 55 60 58 63 54 61 59

Compare with a generated frame in the nineties and a local edit with one hot tile. This pattern is neither.

A genuine night-mode photograph. Nothing dramatic, but every tile is warm, which is the signature of global processing.

Family four: deliberate evasion

The smallest category and the one people worry about most. Any technique that rewrites pixel relationships lowers a score, and most of them visibly damage the image while doing it.

The exception is compositing. A generated object placed into a genuine photograph keeps real texture across most of the frame, which is why the region map exists and why a whole-frame number alone is not enough for anything adversarial.

What each failure looks like when it lands

Reading a suspicious result backwards
What you seeMost likely causeWhat to do
Genuine photo scores high, evenly warm mapProcessing or compressionRe-check the original file
Genuine photo scores high, one hot tileA legitimate edit, or a flat regionLook at what is in that tile
Generated image scores low, degraded fileCompression or a screenshotTreat as no answer, not a clean result
Generated image scores low, clean fileAn unseen generatorFall back on provenance and sourcing
Score sits in the middle bandNot enough signal either wayFind a better copy
No region map producedImage too small to tileFind a larger copy

What none of this is

It is worth separating limitations from things a detector was never attempting. A tool is not wrong for failing to do something outside its scope.

  • It cannot say who made an image. Nothing in pixels ties a file to a person.
  • It cannot say whether the content is true. A genuine photograph can carry a false caption, and that is the more common deception.
  • It cannot name the generator. Only a credential or a marker in the file can do that.
  • It cannot outline an edit. The region map shows where signal concentrates, not the boundary of a manipulation.

How to build a process that tolerates this

The failures above are permanent features rather than bugs awaiting a fix, so the useful question is how to design around them rather than how to avoid them.

Use more than one kind of signal. Pixels, provenance and publication history fail in different places, and an image that looks wrong to all three is a much stronger finding than one that looks wrong to any of them alone.

Route flags to a person rather than to an action. Every serious failure above becomes tolerable if the consequence of being wrong is that somebody looks harder, and intolerable if the consequence is an automatic rejection.

Ask for the original before concluding anything. A remarkable proportion of wrong results resolve at this single step, because the file you were given is almost never the best copy that exists.

Questions people ask

What is the most common way a detector gets it wrong?
A genuine photograph flagged because the file was degraded. Screenshots, repeated compression and phone night mode all rewrite the texture a detector reads, and all three are ordinary things that happen to images without anybody intending to deceive.
Which failure is the most dangerous?
A confident false negative on output from a new generator. The tool reports the image as clean rather than uncertain, so nothing signals that the answer is unreliable. That is why provenance and sourcing matter even when a pixel check comes back low.
Can I tell in advance whether a result will be reliable?
Often, yes. A large original file straight from a camera with plenty of texture gives a reading you can lean on. A small screenshot of a flat scene forwarded through two apps does not, and knowing that before you look at the number is most of the skill.
Do these limitations apply to all detectors?
The first three families apply to any tool reading pixels, because they are properties of the method rather than of one product. What differs between tools is which generators they have seen and where they set the decision line.
Will these problems be solved?
The degradation problem is inherent: destroyed information cannot be recovered. The unseen-generator problem is structural, because retraining follows release. Accuracy on clean images will keep improving, and neither of those two will disappear.
So when is a detector actually useful?
On a reasonably intact file, as one signal among several, to decide where to look harder. That is a genuinely valuable job. It stops being useful the moment somebody treats the number as the answer rather than as the reason to keep investigating.