TinEye vs Forensically vs ExifTool: Three Different Jobs in Image Verification

Image verification often goes wrong before the first tool is opened.

The mistake is treating every image-analysis product as if it answered the same question.

It does not.

TinEye, Forensically and ExifTool operate on three different evidence layers:

• TinEye asks where matching or modified versions of an image appear in its web index.
• ExifTool reads metadata embedded in the file itself.
• Forensically helps an analyst inspect visual and structural anomalies inside an image.

Those are different jobs.

A reverse-image match is not metadata.

Metadata is not proof of authenticity.

A visual anomaly is not proof of manipulation.

The right question is therefore not:

Which image-verification tool is best?

It is:

Which evidence layer do I need to inspect, what does this tool actually observe, and what conclusion is justified by that observation?

---

The short answer

Use TinEye when your question is:

Where else has this image appeared, and can I find earlier or modified versions?

Use ExifTool when your question is:

What metadata is embedded in the file I actually possess?

Use Forensically when your question is:

Are there visual or structural features worth closer forensic scrutiny?

A serious verification workflow may use all three.

The value comes from keeping their outputs separate.

---

Comparison at a glance

This table describes workflow fit.

It is not a quality ranking.

---

Start with the artifact you actually have

Before choosing a tool, identify your input.

You may have:

• the original file from a camera or source;
• a downloaded image from a website;
• a social-media re-encode;
• a screenshot;
• a messaging-app copy;
• a thumbnail;
• an image URL;
• only a visual crop.

These are not equivalent.

A social platform may strip metadata.

A screenshot creates a new file.

A messaging app may recompress the image.

A downloaded copy may contain metadata inserted by the publishing platform rather than by the original camera.

Your first evidence note should therefore record:

artifact source
download method
original filename if available
file size
hash
retrieval time
source URL or message context

Before you interpret metadata or visual anomalies, preserve the exact file you received.

---

Preserve the original before analysis

If the image matters, create an evidence baseline before processing it.

A lightweight workflow is:

original file
↓
SHA-256 hash
↓
read-only analysis
↓
working copies for transformations

Do not repeatedly resave the only copy.

JPEG recompression can create new artifacts.

Editing software can rewrite metadata.

Screenshots destroy much of the original file-level context.

Forensically and ExifTool are most useful when you can still distinguish:

the received artifact

from:

a later derivative created during analysis.

---

TinEye: web provenance and reuse

TinEye is a reverse-image search engine.

Its current documentation explains that it uses image recognition rather than filenames, metadata or watermarks.

When you submit an image, TinEye creates a compact image fingerprint and compares it against its indexed images.

Its goal is to find matching images, including versions that may have been:

• cropped;
• resized;
• edited;
• otherwise modified while remaining recognizably the same underlying image.

This is a fundamentally different task from text-based visual similarity.

TinEye says it does not typically search for merely similar subjects.

It searches for image matches.

---

What TinEye is good at

TinEye is especially useful for questions such as:

• Has this image appeared online before?
• Can I find an older occurrence?
• Has it been cropped?
• Has it been recolored or edited?
• Is there a higher-resolution version?
• Does the same image appear on another domain?
• Is a current viral image actually old?

That makes TinEye a provenance and reuse tool.

It helps you reconstruct how an image has circulated.

---

A TinEye match is an observation about the index

Suppose TinEye returns:

example-news.com/image.jpg

dated earlier than the post you are investigating.

A defensible observation is:

TinEye returned a matching image from example-news.com, and that result may provide an earlier public occurrence to investigate.

Then open the result and verify:

• actual page date;
• page context;
• whether the image is truly the same;
• whether the date is trustworthy;
• whether an even earlier source exists.

Do not turn one search result into:

This is definitely the original source.

The earliest result in one index is not automatically the first publication on the internet.

---

No TinEye result does not prove originality

This is one of the most important reverse-image-search rules.

TinEye searches its own index.

A zero-result search can mean:

• the image has not been indexed;
• the relevant page is not crawlable;
• the copy is too transformed;
• the source is private;
• the image is new;
• the image exists in another index but not TinEye's.

Therefore:

no match found

means:

no matching result was returned from this search against TinEye's index.

It does not mean:

this image is original.

---

TinEye can help order candidate versions

TinEye offers sorting and filtering that can help compare matches.

Useful investigative actions include:

• sort by oldest;
• sort by biggest image;
• filter by domain;
• compare the submitted image with a result.

The "oldest" result can be an excellent lead.

But still verify the page.

Index dates, crawl dates and page publication dates are different concepts.

The analytical chain should be:

TinEye candidate
→ open source page
→ inspect context/date
→ corroborate

not:

TinEye oldest
→ original source confirmed

---

TinEye does not analyze the file's internal metadata

TinEye's own documentation explicitly says its reverse search does not rely on image filenames or metadata.

That is a feature for matching.

It also means TinEye is not the right tool for questions such as:

• Which camera model is listed?
• Is GPS stored in the image?
• Which software tag is embedded?
• Does the file contain XMP?
• Is there an embedded timestamp?

Those questions belong to ExifTool or another metadata parser.

---

TinEye and privacy

TinEye currently states that submitted search images are not added to its index and are only kept briefly for processing/results.

That is useful privacy information.

It does not remove the need for judgment.

Before uploading any sensitive artifact to any third-party service, ask:

• Is remote submission appropriate?
• Does the image contain sensitive personal data?
• Is the investigation confidential?
• Can the same question be answered using a public image URL or a local method?

Tool privacy policy and investigative OPSEC are related, but not identical.

---

ExifTool: file metadata inspection

ExifTool is a mature command-line and library ecosystem created by Phil Harvey for reading and writing metadata across a very wide range of file types.

Its current documentation defines the core function directly:

read and write meta information in files.

For image verification, the most important capability is often read-only extraction.

ExifTool can expose metadata from formats and metadata families including:

• EXIF;
• IPTC;
• XMP;
• maker notes;
• GPS;
• file-system attributes;
• timestamps;
• camera-related fields;
• software-related fields;
• orientation and dimensions;
• thumbnails/previews in supported cases.

It supports far more than image files, which also makes it useful in document and media workflows.

---

What ExifTool is good at

Use ExifTool when the file itself is part of the evidence.

Questions include:

• Does the file contain EXIF?
• Which camera make/model is declared?
• Is GPS stored?
• Which timestamps exist?
• Which software edited or created the file according to metadata?
• Are there embedded comments?
• Is XMP present?
• Does the file contain an embedded preview?
• Are there metadata inconsistencies worth investigating?

This is file-level evidence.

It is not web provenance.

---

Metadata is a claim inside the file

Suppose ExifTool returns:

Make: Canon
Model: EOS ...
DateTimeOriginal: ...
GPSLatitude: ...
Software: ...

The strong observation is:

These metadata fields are present in the file and contain these values.

The unsafe conclusion is:

The image was definitely taken by this camera at this location and time.

Metadata can be:

• altered;
• copied;
• stripped;
• rewritten;
• generated by software;
• stale;
• inconsistent.

Metadata is evidence.

It is not self-authenticating truth.

---

Metadata absence is weak evidence

Suppose ExifTool returns very little.

That may happen because:

• social media stripped EXIF;
• messaging software re-encoded the image;
• screenshotting created a new file;
• export software removed metadata;
• the original device did not populate a field;
• the file format or workflow did not preserve it.

Therefore:

no GPS metadata

does not mean:

the image was not geotagged when originally captured.

It means:

no usable GPS metadata was observed in this artifact.

The artifact history matters.

---

Timestamps need names, not just values

An image can expose several dates.

Examples include:

• file modification date;
• metadata modification date;
• original capture date;
• digitization date;
• XMP dates;
• filesystem dates.

Do not write:

The image date is 12 May.

Write:

DateTimeOriginal contains X.

or:

the filesystem modification timestamp is Y.

Different timestamps describe different events.

If they conflict, that is a question.

Not automatically proof of manipulation.

---

Software metadata is a useful clue

A field such as:

Software: Adobe Photoshop ...

can support:

The file declares software metadata consistent with processing by that software.

It does not prove:

• which edits were made;
• who made them;
• whether the content is deceptive;
• whether the image is fake.

Many legitimate workflows use editing software for:

• cropping;
• color correction;
• export;
• resizing.

The context determines significance.

---

ExifTool can also write metadata — be careful

ExifTool is not only a reader.

It can:

• modify;
• copy;
• delete;
• create

metadata in supported formats.

For investigative work, prefer read-only operations on the preserved original.

If you need to test write behavior:

• use a working copy;
• keep the original untouched;
• document the transformation.

ExifTool's command-line documentation notes that when writing it normally preserves an _original backup by default, but evidence workflows should still control originals explicitly.

Do not rely on application defaults as your evidence-management policy.

---

Forensically: visual and structural inspection

Forensically is a browser-based set of image-forensics tools created by Jonas Wagner.

Its own help page gives the right conceptual model:

think of it as a magnifying glass.

That is one of the most useful descriptions in image verification.

Forensically can expose clues that deserve attention.

It cannot tell you whether an image is "true" or "false."

Its current tools include capabilities such as:

• magnifier;
• clone detection;
• Error Level Analysis;
• noise analysis;
• level sweep;
• luminance gradient;
• PCA;
• metadata display;
• geotag display;
• thumbnail analysis;
• C2PA content-authenticity display;
• JPEG analysis;
• string extraction.

This makes Forensically broader than a single ELA tool.

---

Forensically is local to the browser

The current Forensically FAQ states that opened images stay on the user's computer and are not uploaded to a cloud/server.

It also supports offline use in modern browsers.

This is an important operational advantage for:

• sensitive material;
• confidential investigations;
• artifacts you do not want to submit to a remote search service.

Privacy-friendly local analysis does not change the evidentiary limits of the tools.

It simply changes where the processing happens.

---

Clone Detection: a candidate anomaly, not a verdict

Forensically's clone detector looks for similar regions inside an image.

This can help identify possible copy-move operations.

But similar regions can also arise from:

• repeated textures;
• architecture;
• vegetation;
• patterns;
• compression;
• natural repetition.

Forensically itself notes that the clone detector is not a definitive truth detector and that its algorithm requires filtering and clustering to reduce uninteresting matches.

A clone-detection result should therefore be written as:

Similar internal regions were detected and deserve contextual review.

Not:

This proves the image was manipulated.

---

Error Level Analysis is easy to overread

Error Level Analysis compares an image with a recompressed version.

Differences in compression response can make some regions look different.

That can be useful for spotting areas that deserve closer examination.

Forensically explicitly warns that ELA results can be misleading.

This warning should be treated as part of the tool, not a footnote.

ELA output can be influenced by:

• JPEG quality;
• previous saves;
• local image complexity;
• edges;
• gradients;
• compression history;
• recompression settings.

Bright region does not mean:

Photoshop.

Dark region does not mean:

authentic.

ELA is a visualization of compression behavior.

The analyst must explain the alternative causes.

---

Noise analysis and luminance are supporting clues

Forensically's noise analysis attempts to isolate noise patterns.

Its luminance-gradient tool helps inspect brightness transitions and edge differences.

These can help surface:

• inconsistent texture;
• warping;
• airbrushing;
• perspective-corrected cloning;
• unusual edges;
• illumination anomalies.

But real scenes are complicated.

Different surfaces, lenses, exposure, compression and local edits can all create variation.

Use multiple methods.

Do not make a high-impact authenticity conclusion from one visual filter.

---

PCA can reveal structure that is hard to see directly

Forensically also exposes Principal Component Analysis views.

PCA can separate variance patterns in the image and make some structures more visible.

This can be useful as an exploratory view.

It should not be described as:

AI fake detector

or:

manipulation classifier.

PCA transforms the data.

Interpretation remains human.

---

Thumbnail analysis can expose useful inconsistencies

Some image files contain embedded preview images.

Forensically can display an embedded thumbnail and compare it visually with the main image.

This can be useful when:

• the preview differs from the main image;
• the preview preserves earlier content;
• camera/software behavior leaves a meaningful discrepancy.

But a difference does not automatically mean malicious editing.

Software can regenerate or preserve thumbnails inconsistently.

The correct finding describes the discrepancy.

---

C2PA is another metadata layer — not automatic truth

Forensically now includes a basic C2PA content-authenticity metadata viewer.

This is a useful addition.

The tool's own help page makes the correct warning:

even signed metadata is not inherently trustworthy.

A signed provenance chain can provide important information about:

• signing identity;
• edits;
• assertions;
• credential chain.

It still requires interpretation.

Cryptographic validity does not mean every human claim attached to the file is true.

For deeper C2PA analysis, Forensically recommends dedicated Content Credentials verification or C2PA tooling.

---

Forensically also has metadata features — so why use ExifTool?

This is a useful comparison nuance.

Forensically can display:

• EXIF metadata;
• GPS;
• JPEG structure;
• strings;
• other image-specific artifacts.

So the distinction:

Forensically = pixels
ExifTool = metadata

is too simplistic.

The better distinction is:

Forensically is an interactive image-forensics workspace that includes some metadata views.

ExifTool is a dedicated, deep metadata extraction/manipulation engine across a huge range of formats.

If metadata is central to the investigation, ExifTool is the stronger specialist.

If visual inspection is central, Forensically provides a more integrated interactive environment.

---

Three tools, three evidence layers

Think of the workflow like this.

Layer 1 — Web provenance

Tool:

TinEye

Observation:

matching image appears at URL X.

Layer 2 — File provenance clues

Tool:

ExifTool

Observation:

artifact contains metadata field Y with value Z.

Layer 3 — Visual/structural clues

Tool:

Forensically

Observation:

region A shows anomaly pattern B under method C.

Then add a fourth layer:

Layer 4 — Contextual verification

Sources:

• source page;
• archives;
• official material;
• geolocation;
• fact-check databases;
• eyewitness/context evidence.

That is where image verification becomes an investigation rather than a tool demo.

---

Best order of use depends on the artifact

There is no universal tool order.

If you have the original file

A strong sequence is:

preserve + hash original
↓
ExifTool
↓
TinEye if remote search is appropriate
↓
Forensically on original/working copy
↓
contextual corroboration

Why ExifTool early?

Because you want to inspect file metadata before creating derivatives or accidentally altering the artifact.

If you only have an online image URL

A useful sequence may be:

preserve source URL/page
↓
download image
↓
hash file
↓
TinEye
↓
ExifTool
↓
Forensically

If you only have a screenshot

Recognize the limitation first.

The screenshot metadata describes the screenshot artifact.

Not the original image that appeared on screen.

Reverse search and visual-context methods may become more useful than camera metadata.

---

Worked example 1 — old photo reused as breaking news

Claim:

This photo shows today's explosion.

TinEye

TinEye returns matching versions from three years earlier.

That is a strong lead.

Open the earlier pages.

Verify:

• publication dates;
• context;
• location;
• whether the same image is genuinely used.

ExifTool

The social-media download contains almost no useful EXIF.

That is unsurprising.

Do not write:

metadata proves nothing was edited.

The platform likely changed the file.

Forensically

No obvious clone anomaly appears.

That does not rescue the current claim.

The stronger evidence is provenance:

the image existed years before the claimed event.

The tools answer different questions, and only one may be decisive.

---

Worked example 2 — file with GPS metadata

You receive a JPEG directly from a source.

Preserve

Hash the file.

Keep the original.

ExifTool

The file contains:

GPS coordinates
DateTimeOriginal
camera model

These are valuable clues.

But they are still metadata claims inside the file.

TinEye

No results.

Do not conclude the image is original.

Forensically

Visual analysis shows no obvious anomalies.

Do not conclude the image is authentic.

Next step

Corroborate the GPS against:

• visible landmarks;
• terrain;
• sun/shadows if relevant;
• known source context.

The metadata generates a hypothesis.

Independent visual context tests it.

---

Worked example 3 — suspected copy-move manipulation

An image contains a suspicious repeated object.

Forensically

Clone Detection highlights similar internal regions.

This supports:

repeated visual regions deserve review.

ExifTool

Software metadata shows the file was exported by an image editor.

This supports:

the artifact passed through editing software.

That is common and not proof of deceptive manipulation.

TinEye

An older matching version lacks the duplicated object.

Now the evidence becomes much stronger.

The combination is:

older web version
+ current visual anomaly
+ file-processing clue

The conclusion should still describe exactly what changed rather than simply saying:

fake.

---

Worked example 4 — no metadata, no reverse match, no anomaly

This is common.

TinEye:

0 matches

ExifTool:

minimal metadata

Forensically:

nothing remarkable

What can you conclude?

Very little.

You can conclude:

• no TinEye match was returned;
• this artifact exposes little metadata;
• no obvious anomaly was identified using the methods you applied.

You cannot conclude:

authentic image.

Absence of suspicious evidence is not proof of authenticity.

---

Worked example 5 — C2PA credentials present

Forensically displays C2PA content-authenticity information.

That can become a valuable provenance layer.

Inspect:

• signer;
• assertions;
• edits;
• chain;
• verification status.

Then ask:

• Is the signer meaningful?
• Is the credential valid?
• Does the provenance chain cover the relevant artifact history?
• Does the human interpretation match the signed assertions?

C2PA can strengthen provenance reasoning.

It does not eliminate the need for source and context verification.

---

The "earliest image" problem

Investigators often want the original source.

Reverse-image search is useful here.

But "earliest result" can mean several different things:

• oldest indexed result;
• oldest known page;
• oldest page still online;
• oldest archived copy;
• actual first publication;
• original photographer/source.

Those are not identical.

A better workflow is:

1. use TinEye to identify early candidates;
2. inspect those pages;
3. use archives;
4. trace credits/captions;
5. compare image resolution;
6. follow photographer/agency attribution.

The first reverse-search result is a lead.

Not necessarily the origin.

---

Original file versus internet derivative

This distinction should drive the whole workflow.

Original or near-original file

Metadata may be rich.

File structure may matter.

ExifTool and Forensically gain value.

Internet derivative

Metadata may be stripped.

Compression may be repeated.

ELA/noise results become harder to interpret.

Web provenance may become more useful.

Screenshot

File metadata mostly describes the screenshot creation.

Original compression/provenance may be lost.

Reverse-searching a crop can still help, but the evidence layer has changed.

Always describe which artifact you analyzed.

---

Do not compare visual-forensics outputs across different JPEG histories casually

Two files showing the same scene can have different:

• JPEG quality;
• scaling;
• color profile;
• recompression history;
• sharpening;
• social-platform processing.

ELA and noise views can therefore differ dramatically without any deceptive editing.

If you compare two versions:

• preserve both;
• record dimensions;
• record file sizes;
• inspect metadata;
• note likely recompression.

Do not treat filter differences as semantic differences automatically.

---

ExifTool and Forensically should usually be run on a preserved local copy

For important artifacts:

EV-001_original.jpg

becomes immutable.

Then analyze:

EV-001_working.jpg

if you need transformations.

ExifTool read-only extraction can target the original.

Forensically can inspect the original file locally in the browser.

If you export annotated screenshots from Forensically, store them as derived artifacts.

Do not replace the original with the annotated image.

---

TinEye results need preservation too

Reverse-search results are also volatile.

Pages disappear.

Search indexes change.

When a match matters, record:

• query image hash;
• TinEye search time;
• result URL;
• result domain;
• displayed date/sort context;
• local screenshot if appropriate;
• source page capture;
• your interpretation.

Do not preserve only:

"TinEye found it."

The useful evidence is the underlying source page and the relationship to the query image.

---

Privacy and OPSEC decision

The tools have different privacy models.

TinEye

Remote service.

TinEye currently says submitted images are not added to its index and are kept only briefly for search processing/results.

Still decide whether submission is appropriate.

ExifTool

Local command-line/library processing.

The file does not need to leave your environment.

Forensically

Current Forensically documentation says images remain on the user's computer and are not uploaded.

It can also work offline.

For sensitive investigations, local processing can be an important workflow choice.

Do not confuse:

privacy-friendly processing

with:

stronger evidentiary conclusion.

They are different dimensions.

---

A practical decision matrix

Again, this is first-tool fit.

Serious verification usually combines methods.

---

Common mistakes

Mistake 1 — Calling all three "forensics tools"

TinEye is primarily reverse-image search.

Mistake 2 — Treating no TinEye result as originality

Index coverage is incomplete.

Mistake 3 — Treating metadata as truth

Metadata is editable.

Mistake 4 — Treating no metadata as suspicious

Platforms often strip it.

Mistake 5 — Treating ELA brightness as proof of Photoshop

ELA is affected by compression history.

Mistake 6 — Treating clone detection as automatic manipulation confirmation

Natural repetition can produce candidate matches.

Mistake 7 — Using only a social-media derivative for file-level conclusions

The platform may have rewritten the artifact.

Mistake 8 — Resaving the original before hashing it

Preserve first.

Mistake 9 — Running a local forensic tool and assuming privacy proves authenticity

Processing location and evidence meaning are separate.

Mistake 10 — Saying "C2PA verified, therefore image true"

Signed provenance still needs interpretation.

Mistake 11 — Treating editing software metadata as deception

Legitimate images are routinely edited/exported.

Mistake 12 — Forgetting source context

Image verification is not complete until the surrounding claim is tested.

---

A repeatable three-tool workflow

If the image matters enough to use all three:

1. Preserve the artifact

Record:

• source;
• URL/context;
• timestamp;
• file hash.

2. Identify artifact type

Original?

Download?

Social derivative?

Screenshot?

3. Inspect metadata

Use ExifTool.

Record the actual tag names and values.

Separate:

file timestamp
EXIF original timestamp
GPS
software
camera

4. Search web provenance

Use TinEye if submission is appropriate.

Record matches as candidates.

Inspect underlying pages.

5. Inspect visual structure

Use Forensically.

Use several views when relevant.

Do not rely on one filter.

6. Compare evidence layers

Ask:

• Does metadata support the claimed context?
• Does web history contradict it?
• Do visual anomalies have alternative explanations?
• Is the artifact likely to have been recompressed?

7. Corroborate externally

Use:

• source page;
• archives;
• fact checks;
• geolocation;
• official media;
• original photographer/agency material.

8. Write the narrowest supported conclusion

Prefer:

A matching version of the image appears on an older page from year X, contradicting the claim that the image was first captured today.

over:

The image is fake.

The first describes evidence.

The second may be broader than the evidence supports.

---

Related OSINT.dev tools

TinEye

Best for:

• reverse-image matching;
• image reuse;
• older public occurrences;
• modified copies.

ExifTool

Best for:

• deep metadata extraction;
• EXIF/IPTC/XMP;
• camera/software/GPS fields;
• file-level inspection.

Forensically

Best for:

• interactive visual anomaly inspection;
• clone detection;
• ELA;
• noise;
• luminance;
• PCA;
• thumbnail/JPEG/C2PA views.

Google Fact Check Explorer

Use separately when the investigation concerns:

Has a matching or related claim already been fact-checked?

That is a claim-verification layer.

It is not a substitute for image provenance or file analysis.

---

The core principle

The three tools answer three different questions:

TinEye — Where has this image appeared?

ExifTool — What metadata does this artifact contain?

Forensically — What visual or structural clues deserve closer inspection?

None answers:

Is this image true?

That conclusion comes from combining:

• artifact provenance;
• file-level clues;
• visual analysis;
• source context;
• historical evidence;
• independent corroboration.

Use each tool as a lens.

Do not mistake the lens for the verdict.

---

References

Official/current documentation used in this comparison:

• TinEye — What is TinEye?
  https://help.tineye.com/article/231-what-is-tineye

• TinEye — How does TinEye work?
  https://help.tineye.com/article/233-how-does-tineye-work

• TinEye — How to use TinEye to search for an image (2026)
  https://blog.tineye.com/how-to-use-tineye-search/

• TinEye API — Reverse Image Search
  https://services.tineye.com/TinEyeAPI

• ExifTool — Current official command-line documentation
  https://exiftool.org/exiftool_pod.pdf

• ExifTool — Official project site
  https://exiftool.org/

• Forensically — Photo Forensics for the Web
  https://29a.ch/photo-forensics/

• Jonas Wagner — Forensically: Photo Forensics for the Web
  https://29a.ch/2015/08/16/forensically-photo-forensics-for-the-web