Why screenshots defeat the usual AI-detection signals
When a detector analyses an original AI-generated image, it has several attack surfaces available. Frequency-domain fingerprints left by the upsampling pipeline. Watermarks embedded in the pixel distribution at a sub-visible level. Generator-specific EXIF tags, canvas dimensions that match a known default, and provenance credentials attached to the file. These signals survive the journey from generator to your disk largely intact.
A screenshot erases most of them in one step. The capture tool reads the screen buffer — a rendered, composited, hardware-accelerated frame — and writes a new image file from scratch. The original pixels are gone; what remains is a re-encoded copy of what was displayed on a monitor. Frequency watermarks are destroyed by the rendering pipeline. EXIF does not exist in a screenshot file. Canvas dimensions are now the dimensions of the screenshot crop, not the generator output. The only signals that survive are visual ones embedded in the pixel content itself.
That is not nothing. Generated UI screenshots reproduce the overall look of real interfaces but tend to get specific constraints wrong — and those violations are visible to a careful human reader even when they are invisible to a frequency-domain classifier.
What the heuristic check above can surface
The checker reads three file-level properties. First: whether the file has any EXIF metadata at all. Screenshots almost never do — the capture process creates a fresh file with no camera provenance. But this signal is weak in isolation because a real camera photo posted to a social platform has the same empty-EXIF signature. Mark it as a baseline condition, not evidence.
Second: whether the pixel dimensions match a known generator canvas. Stable Diffusion's standard outputs include 512×512, 768×512, and 1024×1024. DALL·E 3 defaults to 1024×1024, 1024×1792 and 1792×1024. Midjourney uses 1456×816 and 1456×1456 among others. A screenshot cropped to those exact dimensions is a mild signal. Note that "mild" is accurate — a screenshot cropped to 1024×1024 on any phone or monitor is not unusual.
Third: whether any embedded text chunk names a generation tool. Some generators write their name into a PNG tEXt field even when output as a screenshot-like file. When this fires, it is the strongest file-level signal available. When it does not fire, the absence means nothing.
The checker labels each finding with a confidence note and states clearly that the result is heuristic. It does not produce a percentage score or a binary verdict — because producing one would misrepresent what the data supports.
The manual inspection checklist for UI screenshots
Visual inspection by a person who knows what real interfaces look like remains more reliable than automated analysis on screenshots. The five areas below are where generated UI screenshots most often fail.
| Area | What to examine | Common AI tell |
|---|---|---|
| Typography consistency | Font weight, letter-spacing and baseline alignment | Characters that shift weight mid-word, descenders that clip the line below, or kerning that tightens and loosens across a heading without reason |
| UI component alignment | Button padding, icon centering, input border radius | Padding that differs between visually identical buttons, icons that sit fractionally off-centre, or border radii that change on the same component type |
| Shadow and depth | Drop-shadow direction, blur radius, spread | Shadows that come from inconsistent light sources across the same screenshot, or blur that increases on smaller elements where it should be tighter |
| Scrollbar and chrome | Scrollbar position, OS-style window decoration | Scrollbars that float off the edge or appear on both axes without overflow, title-bar icons from two different operating systems in the same window |
| Text content logic | Readable sentences, coherent labels, realistic data | Navigation labels that contradict the page content, form fields with placeholder text that does not match the field type, dates or numbers in a format no real app would use |
No single item on that list is conclusive. Real screenshots from production apps contain bugs — misaligned labels, inconsistent spacing, the occasional glitchy shadow. Look for clusters of anomalies across two or more categories rather than acting on one odd padding value in isolation.
Five real scenarios where screenshot AI detection comes up
A freelancer receives a "mockup approval" screenshot before starting a project. The layout is suspiciously polished — every component looks like a design system without being any specific one. Checking the EXIF block shows no software tag; dimensions match a Midjourney square output. The client may have generated a concept image rather than approved actual work from a designer. Worth confirming before billing assumptions are set.
A journalist receives a screenshot of a banking app showing an unusual transaction. The font weights on the transaction label shift mid-word, and the currency symbol uses a character that does not appear in the real app. Neither fact proves fabrication, but both are grounds for requesting the original device and the app itself as corroboration.
A hiring manager receives a screenshot of a candidate's supposed work — a dashboard UI attributed to a previous employer. The scrollbar floats 4 pixels off the edge, which is not a browser rendering artifact; it is the kind of near-correct geometry that generators produce. Asking for a screen recording of the live product is a reasonable follow-up.
A moderation team reviews a screenshot of a conversation that supposedly shows harmful messages. The message timestamps follow no consistent format — some in 12-hour, some in 24-hour, mixed across the same thread. Real messaging apps pick a locale and stick to it. That inconsistency is the kind of detail generators regularise incorrectly.
A content researcher tracks AI-generated product listings on a marketplace. Sellers submit screenshots of supposed review dashboards showing inflated scores. The star icons in three consecutive screenshots have subtly different aspect ratios, and the review counts use a comma separator that the actual platform does not. Small tells, but consistent across a batch.
Four common misconceptions about detecting AI in screenshots
Misconception: a high AI score from a general-purpose detector means the screenshot is generated. Most general-purpose detectors are trained on AI-generated photographs, not AI-generated UI mockups. A screenshot of a real interface can score as "likely AI" on a detector that is actually reading the clean pixel compression of the screenshot format itself, not the content.
Misconception: if the screenshot contains readable, coherent text, it must be real. Language models produce coherent text far more reliably than they produce coherent UI layout. A generated screenshot can carry perfectly sensible sentences while the surrounding chrome is visually impossible for any real renderer. Text quality is a weak signal for UI screenshots specifically.
Misconception: small dimensions mean it was taken on a real phone, so it must be real. Generators can output images at phone-typical dimensions, and screenshots can be cropped or downscaled to any size. Dimensions tell you about the file, not the device or the origin.
Misconception: if you cannot prove it is fake, you should treat it as real. Burden of proof matters here — especially in editorial, legal, and moderation contexts. The right frame is not "innocent until proven generated" but "what corroboration would confirm the claimed source?" Asking for device access, original files, or a screen recording costs the legitimate sender very little and settles the question.
Privacy: what this checker does and does not do
The heuristic check runs entirely in your browser using the same local File API as the photo metadata viewer. Your screenshot is not transmitted to any server. You can confirm this in the browser network panel — there are no outbound requests after you drop the file.
The checker does not use a remote AI model to classify the image, because doing so would require uploading the file. Useful as remote classification sometimes is for photographs, for screenshots it often performs below human visual inspection anyway, so the trade-off — giving the file to a third-party server — is not worth it. The checklist above and the file-level signals in the tool together cover the tractable ground without that cost.
Screenshot compression: what survives a re-encode
Every screenshot involves at least one re-encode. When the operating system composites the display buffer and saves it as a file, it applies its own codec and quality settings. If the original content was a PNG — lossless — and the screenshot is saved as JPEG, the codec applies discrete cosine transform quantisation, and the high-frequency detail in the image is gone. Chroma subsampling at 4:2:0, the JPEG default, averages colour information across 2×2 pixel blocks, which erases fine coloured noise patterns. That erasure matters for forensics: many AI generators leave faint spectral artefacts in the frequency domain that analysts can measure in an original file. After a JPEG re-encode those signals are buried under quantisation noise, or removed entirely.
The same erasure affects real-camera evidence in the opposite direction. Sensor noise and demosaicing patterns from a physical camera are also high-frequency signals. A screenshot of a photograph — taken at 200% zoom on a monitor, or forwarded through a messaging app that recompresses on upload — loses most of that sensor fingerprint. Multiple screenshot generations (a screenshot of a screenshot) add downscaling and interpolation artefacts that look nothing like either source. The practical expectation for screenshot forensics is therefore modest: a screenshot can support a finding, but it cannot carry a finding on its own. Treat it as one piece of corroborating evidence, not a definitive verdict.
Cropping and resizing before you inspect
Before you open a screenshot in any inspection tool, preserve the original. Copy the file and work only on the copy. Do not resize or scale up before you begin: upscaling runs an interpolation pass — bicubic, Lanczos, or a neural super-resolution — which synthesises edges and textures that did not exist in the source pixels. Inspecting those synthesised pixels as if they were original is a source of false positives. If the screenshot is small, zoom your viewer to 100% and pan rather than scaling the image itself. Do not convert formats before inspection either; converting PNG to JPEG introduces compression artefacts independent of anything in the original content.
When you need to compare a suspicious screenshot against a baseline, take a fresh reference screenshot of the same UI element on a known real device at the same display scale. Align the two at 100% zoom and look at the same region. Differences in rendering, anti-aliasing, and subpixel layout between real and AI-generated interfaces tend to be visible at that scale in ways that survive typical JPEG quality settings. The three-step discipline is: retain the original unmodified file, duplicate it, and perform all operations only on the duplicate. If the duplicate is ever further compressed or transformed, note that in your record so a later reviewer knows the chain of custody.
What to write down when a screenshot is your only evidence
If a screenshot is the sole artefact available, the quality of your written record determines whether the finding is usable later. Note the source channel and acquisition time: where the screenshot came from (direct capture, forwarded message, downloaded attachment), whether it was re-compressed in transit, and the timestamp of your own copy. Record the file properties: reported resolution, colour depth if visible, and the display scaling factor of the device that produced it. Note whether the file is the original capture or has already passed through a third-party app. If the messaging platform is known to recompress attachments, say so explicitly.
For the inspection findings themselves, identify the region under scrutiny by pixel coordinates or a described bounding area rather than by impression alone. Write observations in bounded language: "the text rendering in the top-left 200×50 px region shows uniform stroke width inconsistent with the subpixel hinting visible in reference screenshots of the same application" is a supportable observation. "This is AI-generated" is not, because a screenshot alone cannot exclude other explanations — screen recording artefacts, aggressive system font smoothing, or an older OS version with different rendering defaults. The conclusion should name what the evidence is consistent with, not assert what the source must be. Keeping that distinction in your written record protects the finding if it is reviewed by someone who was not present during the inspection.
How this page relates to the other tools on this site
The AI-generation checker is designed for original image files — files that came directly from a camera or a generator without passing through a screenshot step. It reads EXIF completeness, provenance credentials, generator tags, and canvas dimensions in that fuller context. Use that tool when you have the original file; use this page when you only have a screenshot.
The detection explainer covers the underlying methods — frequency analysis, noise residuals, semantic plausibility — in more depth. Reading it helps calibrate what you should and should not expect from any detection tool, including this one.
If the screenshot you are checking comes with an original image file — the generator output before it was screenshotted — use the original-file checker on that version instead. The file-level signals there are far stronger than anything a screenshot can carry.