Fraud teams, investigators and verification desks are now asked every day whether a photo is genuine, and no single tool can answer that question. Image forensics is the examination of a digital image to establish where it came from, whether it has been altered, and whether it shows what it claims to show. This guide covers the practical workflow: metadata and EXIF analysis, error level analysis and other pixel-level checks, reverse image search, provenance signals, telling an edited photo apart from a fully synthetic one, and handling images as evidence in insurance claims, KYC onboarding and incident investigations. It is written for fraud analysts, DFIR practitioners, trust and safety teams and anyone who signs off on photographic evidence. For the C2PA provenance standard itself, see the AI Content Provenance and C2PA Guide; for video and voice, see the Deepfake and AI Impersonation Guide.
Key takeaways
- Combine independent signals. Metadata, pixel analysis, reverse search, provenance and context each fail in known ways; a conclusion should rest on several that agree.
- Absence proves nothing. Missing metadata is normal for images shared through messaging apps and social platforms, and NIST AI 100-4 notes that metadata can be stripped or altered by anyone who copies a file.
- ELA shows compression history, not intent. Error level analysis highlights regions with a different save history; its own authors warn it is not proof and must be checked with other methods.
- Detectors are probabilistic. NIST reports that synthetic content detectors make errors, lose accuracy on unfamiliar generators and after compression or resizing, and that unaided human judgement is not reliably better than chance.
- Evidence handling decides whether findings count. Preserve the original file, hash it, work on copies and record every step, or a correct conclusion may not survive a dispute.
Altered, generated or misattributed: know what you are testing
"Is this photo fake?" hides three different questions, and each needs a different method.
| Category | What it means | Typical example | Strongest methods |
|---|---|---|---|
| Digitally altered | A real capture that has been edited: objects added or removed, text changed, regions cloned or spliced | Damage added to a car photo for an insurance claim; amended figures on a photographed invoice | Pixel analysis (ELA, clone detection, noise and lighting consistency), metadata software tags, comparison with an earlier copy |
| Digitally generated (synthetic) | Created wholly or largely by a generative model, with no real scene behind it | A fake ID selfie, a fabricated disaster image | Provenance signals and watermarks, synthetic content detectors, physical plausibility checks, absence of any earlier source |
| Genuine but misattributed | An unedited real photo used with a false date, place or story | An old flood photo reposted as today's event; a stock photo used as a profile picture | Reverse image search, geolocation and chronolocation, metadata dates |
NIST AI 100-4 makes the last point explicitly: authentic content can still mislead when taken out of context. A pixel-perfect original can be the lie.
Metadata and EXIF analysis
Most cameras and phones write EXIF metadata into JPEG and HEIC files, and editing tools add XMP and IPTC blocks. ExifTool, the widely used open source reader, supports EXIF, GPS, IPTC, XMP, ICC profiles and manufacturer maker notes, and reads far more formats than it can write.
| Field or block | What it can tell you | Caveat |
|---|---|---|
| Make and Model | Claimed capture device; compare with the device the claimant says they used | Easily edited; some apps overwrite it |
| DateTimeOriginal and time zone offsets | When the image was captured according to the device clock | Device clocks can be wrong; compare with file system and upload times |
| GPS tags | Capture location | Often removed by platforms and privacy settings; can be spoofed |
| Software and processing tags | Editing applications that touched the file | Phones record their own processing software; presence of an editor is not proof of a misleading edit |
| Embedded thumbnail | A small preview that may not have been updated after an edit, revealing the earlier content | Many editors regenerate it |
| Maker notes | Manufacturer-specific details such as serial numbers and lens data | Undocumented formats; varies by firmware |
| C2PA manifest (JUMBF) | Signed provenance and edit history where present | ExifTool notes C2PA data cannot be written, only deleted; absence is common |
- Look for internal contradictions: a capture date after the upload date, an editing tag on a file described as "straight from my phone", GPS that contradicts the claimed location, or image dimensions that do not match the stated camera.
- Compare against known-good samples: for KYC and claims, collect reference images from the same device model to learn what its normal metadata and compression look like.
- Record, do not edit: extract metadata to a report from a working copy; never write to the original. ExifTool backs up the original when writing, but evidence copies should be read-only.
Pixel-level analysis: ELA and related checks
Error level analysis
ELA re-saves a JPEG at a known quality and displays the difference from the original as brightness. In an unaltered image, similar surfaces and edges should show similar error levels; a region that stands out may have a different compression history, for example because it was pasted in.
- Known limitations: images re-saved many times lose detail until ELA shows almost nothing; whole-image operations such as scaling, recolouring or added noise mask local edits; JPEG's 8x8 block grid means the exact changed pixels usually cannot be pinpointed; very small edits may not show.
- False positives: some software sharpens edges and textures on save, and coloured "rainbowing" can come from phone processing as well as editors.
- Best source first: results depend on history, so find the earliest, highest-quality copy before analysing. A screenshot of a forwarded image mostly shows the forwarding.
Other checks
- Clone detection: look for repeated regions used to hide objects, often visible as identical texture patches.
- Noise and sensor consistency: every camera sensor leaves a noise pattern; regions with a different noise level or pattern suggest splicing. Sensor identification was one of the tasks NIST evaluated in its Media Forensics Challenge.
- Lighting, shadows and perspective: shadows that point different ways, reflections that do not match, or text that does not follow the surface geometry.
- Recapture and screenshots: moire patterns, screen pixel grids, bezels or glare suggest a photo of a screen, which is a common way to launder an edited image into a "new" capture.
- Document photos: for IDs, invoices and bank statements check font consistency, alignment, character spacing and security features rather than relying on pixel tools alone. See the Top 10 KYC Bypass Techniques.
Reverse image search and context checks
Reverse image search finds earlier or similar copies, which is the fastest way to expose a misattributed photo or a stock image passed off as personal. Google Lens accepts uploads, image URLs and right-click searches from Chrome, and returns sites that host the same or a similar image. Note that Google may store searched image URLs, so do not upload sensitive customer images to public search engines; use internal search or approved tools for KYC and claims evidence.
- Search the whole image, then crops of distinctive areas (faces are often the least useful; signs, buildings and landmarks the most).
- Search mirrored and colour-corrected versions; reposters flip and filter images to evade matching.
- Use more than one engine, because indexes differ.
- Sort or look for the earliest appearance and compare it with the claimed date.
- Geolocate visible features (signage language, road markings, skyline) and check weather and sun position against the claimed date and place.
See the OSINT and Reconnaissance Guide for wider open source techniques.
Provenance and synthetic image detection
NIST AI 100-4 (November 2024) groups the technical approaches into provenance data tracking (digital watermarks, overt or covert, and recorded metadata, which cryptographic signatures and standards such as C2PA make harder to tamper with) and synthetic content detection. It stresses that these are building blocks that work best together.
| Signal | What a positive result means | What a negative result means |
|---|---|---|
| Valid C2PA content credential | A signer made claims about origin and edits; NIST notes a signature shows a claim was made, not that it is accurate | Nothing: most images carry no credential, and it can be stripped |
| Generator watermark detected | Strong indication of that generator's involvement | Nothing: other generators may not watermark, and processing can remove marks |
| Detector flags "likely synthetic" | A probability, which drops on unfamiliar generators and compressed or resized files | Not proof of authenticity |
| Earlier source found by reverse search | The image existed before the claimed event | The image may be new, or simply not indexed |
| Physical implausibility (hands, text, reflections) | A useful lead, especially in older generator outputs | Modern generators often pass visual checks |
For KYC selfies and identity documents, image analysis should sit alongside liveness and presentation attack detection rather than replace it. See the Biometric Liveness and Presentation Attack Detection Guide and the Deepfake-Resistant Identity Verification Guide.
Hidden data and image steganography
Image forensics also asks what an image carries besides the picture. Steganography hides data inside pixel values or file structures so that the image looks normal, and attackers have used it to smuggle payloads and configuration past content filters. In a verification context the practical checks are modest and safe:
- File structure: compare the file size with what the dimensions and quality would normally produce, and look for data appended after the image end marker or unexpected embedded blocks.
- Format mismatches: a file whose extension, header and actual content type disagree deserves closer inspection before anyone opens it in other software.
- Handling: treat suspicious images from untrusted sources as potential malware carriers and analyse them in an isolated environment.
See the Steganography in Attacks Guide for detection in a security operations setting.
Building a repeatable verification workflow
Teams that verify images at volume, such as claims handlers, onboarding operations and newsroom desks, get more consistent results from a written triage workflow than from individual expertise.
- Intake: capture the original file, its source, the claim it supports and the hash.
- Automated screening: run duplicate matching against your own past submissions (the same damage photo reused across claims is a frequent find), metadata extraction and any approved detector.
- Analyst review of flagged items: apply the metadata, pixel, reverse search and provenance checks above, recording each result.
- Decision and feedback: grade the conclusion, act on it, and feed confirmed cases back into duplicate matching and detector testing.
- Periodic calibration: re-test tools on a labelled sample set each quarter, because both cameras and generators change.
Evidence handling for claims, KYC and investigations
- Collect the original file: ask for the file as captured (original HEIC or JPEG, sent as a file or via upload), not a screenshot or a messaging-app copy, which strips metadata and recompresses.
- Hash on receipt: compute a SHA-256 hash of the original and record it with the time, source and collector.
- Store read-only and analyse copies: keep the original in write-protected storage and run every tool on a copy. See the Evidence Handling and Chain of Custody Guide and the Chain of Custody Form Template.
- Log every step: tool name and version, settings (such as the ELA quality level), outputs and screenshots.
- Grade the conclusion: use a scale such as "no indication of manipulation found", "inconclusive", "indications of manipulation" and "manipulation confirmed", and state what was not tested.
- State limitations: SWGDE's guidance on the admissibility of image examinations (23-I-001, November 2025) expects examiners to acknowledge limitations and to be ready to explain reliability under standards such as Daubert and US Federal Rule of Evidence 702. For international practice, see the ISO/IEC 27037 Digital Evidence Guide.
- Escalate high-value cases: send disputed or high-value claims to a qualified examiner rather than relying on an analyst's tool output.
Choosing the level of effort
| Situation | Recommended depth |
|---|---|
| Low-value claim, no red flags | Automated metadata and duplicate checks only |
| Social media verification for a newsroom or comms team | Reverse search, geolocation, metadata where available |
| KYC onboarding at scale | Automated document and selfie checks plus liveness; manual review of flagged cases |
| High-value insurance claim or litigation | Full workflow with chain of custody and an accredited examiner |
Framework mapping
| Activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 |
|---|---|---|
| Analysing an image to establish what happened | RS.AN-03 | None specific |
| Recording investigation actions with integrity | RS.AN-06 | AU-10 Non-repudiation |
| Collecting images and metadata with preserved provenance | RS.AN-07 | SI-7 Software, Firmware, and Information Integrity |
| Verifying identity photos at onboarding | None specific | IA-12 Identity Proofing |
Metrics
- Share of submitted images received as original files rather than screenshots or forwarded copies.
- Confirmed manipulations found per thousand reviewed images, by channel.
- Rate of analyst conclusions overturned on expert review.
- Median time from submission to verification decision.
- Detector false positive rate measured on a labelled internal test set, refreshed as generators change.
Common failure patterns
- Treating missing EXIF as suspicious: most platform-shared images have none, so this produces false accusations against honest customers.
- Reading ELA as a verdict: bright areas from sharpening or high-contrast edges get reported as "edited".
- Trusting a single detector score: a "92% real" score is taken as proof of authenticity, although NIST reports detectors degrade on new generators and recompressed files.
- Analysing the wrong copy: the analyst works on a screenshot of a forwarded image rather than requesting the original.
- Uploading customer evidence to public tools: claims and KYC photos are sent to public search or analysis sites, creating a data protection problem.
- No audit trail: findings are correct but the steps were not recorded, so they cannot be defended in a dispute or complaint.
Practitioner checklist
- Classify each question as altered, generated or misattributed before choosing tools.
- Request original files and hash them on receipt with SHA-256.
- Extract and review EXIF, XMP, IPTC and any C2PA data from a copy.
- Run ELA and clone checks on the best available copy and record the settings.
- Reverse search the image and distinctive crops on more than one engine.
- Treat synthetic detector output as one signal, with a known false positive rate.
- Keep customer images out of public tools unless policy allows it.
- Grade conclusions and state limitations in every report.
- Escalate high-value or disputed cases to a qualified examiner.
Standards and references
- NIST: AI 100-4 Reducing Risks Posed by Synthetic Content
- NIST: Media Forensics Challenge
- SWGDE: Legal and Scientific Support Relating to the Admissibility of Image Examinations
- NIST: Cybersecurity Framework 2.0
- ExifTool: Read, Write and Edit Meta Information
- FotoForensics: Error Level Analysis Tutorial
- Google: Search with an image
Related NHI Mgmt Group resources: AI Content Provenance and C2PA Guide · Digital Forensics (DFIR) Guide · Insurance Fraud Detection Guide · Steganography in Attacks Guide