How to prove when a photo was taken, for an insurance claim or a dispute

A field guide from ChronoVerify, written by a veteran intelligence analyst. Published September 19, 2026

Someone is asking you to show when a photo was taken. An adjuster wants the damage photos dated to the day of the loss. A landlord says the mold was there before you moved in. A buyer says the item arrived broken, and you have a picture of it whole in the box. A screenshot of the photo's properties settles none of this, because the date in that box is a text field anyone can type over. What settles it is the original file, the dates inside it agreeing with each other, and a record of what the file contains that the other side can check without taking your word for it.

What counts as proof of when a photo was taken?

No single field proves a date. There are layers, each harder to fake than the last.

1. The dates inside the file. The camera writes the capture time into the photo as EXIF metadata, with the device and sometimes the GPS position. That is what the "Date taken" box shows. It is plain text and free tools rewrite it in one command, so on its own it is a lead. The capture-time guide shows where it lives on each device.
2. The dates agreeing with each other. A photo carries up to five dates, written by the camera, the app that last saved it, the GPS chip, and your computer. Someone who changes one usually leaves the others behind, and a "last saved" time earlier than the "taken" time means the file's own story is broken. The guide to changed dates lists the contradictions.
3. Evidence outside the file. Google's About this image shows when Google first saw the picture online. Weather, shadows, and a known event in the frame tie the claimed date to the world.
4. A signed Content Credential. Some phones, cameras, and editing apps sign their photos with a C2PA Content Credential that covers the file and the time of signing; change a date afterward and the signature breaks. One that reads as Trusted is the strongest evidence a file can carry. Most everyday photos do not have one yet, and social platforms strip them on upload, so its absence means nothing.
5. A third-party record of what the file contains. If you read the dates yourself and screenshot them, the other side has to trust you twice. A record produced by a third party, signed and timestamped so anyone can check it has not changed, removes both objections. It is still a record of the file, not of the world.

Send the original file, not a screenshot or a forwarded copy

The file you send decides what can be checked at all. A screenshot carries nothing: nothing photographed it, so it has no capture date, device, or location. Photos sent as pictures through WhatsApp, Messenger, Instagram, or X arrive with most metadata removed; the original on the phone that took it is the evidence, and if it has to go through an app, send it as a file or document, which most apps pass through untouched. Cloud exports can be edited copies: on an iPhone, Adjust Date and Time changes the library entry, not the original file, so export the unmodified original, and in Google Photos or iCloud download the original rather than using the share sheet. Leave the first copy on the device that took it and send a copy. If anyone later asks to see the device, you want the file still there.

Check the photo yourself before you send it

Upload the original to the free verifier. It reads every date the file carries, compares them, checks any Content Credential against the official trust lists, runs a pixel analysis for signs of editing, and gives one plain result. The photo is processed for the check and not stored.

• Consistent. The dates agree and nothing in the pixels stood out. The normal result for an honest, unedited photo. It shows the file's story holds together, not that the scene happened.
• Provenance confirmed. A Trusted Content Credential locks the capture time behind a signature anyone can verify. The best outcome a file can give you.
• Metadata anomaly. Two dates cannot both be true. Find out why before you send it: a wrong camera clock, a time-zone change, or a gallery app that rewrote one date can all cause this with no intent to deceive.
• Inconclusive. Too little data to say much, which is what a screenshot, a download, or a re-saved copy looks like. Go find the original.
• Possible editing. Two independent pixel signals point to a change. Ordinary photos almost never trip this; if yours does, understand why before it becomes someone else's finding.

What the signed report contains, and how the other side checks it

When the date matters, ChronoVerify produces a signed PDF report for a single photo for $29, bought at the result screen of the free verifier with no account. Your browser sends the photo once more, after payment, to build the PDF. The report records the file's SHA-256 fingerprint, so anyone holding the same file can confirm the report is about that exact file; every date the file carries, with each check and its outcome; the Content Credential result, with the signer when there is one; the pixel analysis; and the verdict with its confidence and limits, in plain words.

Two things make it checkable by a stranger. It is signed with an Ed25519 signature over the findings, against a public key we publish, so any change after signing is detectable. And it carries an RFC 3161 trusted timestamp from an independent timestamp authority, which shows the report existed at that moment and has not changed since. Paste the three blocks printed in the report into our report checker, which runs in the browser and uploads nothing, or run the openssl command printed in the report offline. Neither step requires trusting us. The person you send it to gets a document that says: this file, with this fingerprint, contained these dates and this credential result, and the finding has been sealed since this time.

What the report does not prove

• That the scene in the photo is real, or that the damage, the mold, or the box looked that way. It reports what the file contains.
• Who took the photo. Content Credentials carry no authorship, and EXIF names a device, not a person.
• That the date is true if every date in the file was rewritten to agree. A careful rewrite leaves no contradiction; only a signed credential or evidence outside the file catches that, and the report says so.
• That an insurer, a platform, a landlord, or a court will accept it. Each sets its own rules for evidence, and we make no claim about any of them. It is a record for review.

The same rules, whatever the dispute

For an insurance claim, send checked originals from the phone that took them, and for a large claim a signed report per key photo; teams on the claims side run the same check as one API call per image. For a rental or marketplace dispute, take the move-in or pre-shipping photos with the phone's own camera app and keep the originals, because the record's job is to fix the time. For a news tip, editors ask for the original file and distrust a date they cannot check, and a signed record answers both.

Honest limits

Every check here reads what the file says about itself. Agreement between dates means nobody made a careless edit and nothing more; a wrong camera clock produces a consistent file with a wrong date. A missing date is not evidence of anything, because platforms strip metadata from honest photos every day. ChronoVerify never turns a later save time or an editing app's name into an accusation, and it needs two independent pixel signals before it flags editing. It is provenance-first: it does not detect AI generation or deepfakes, and a signed report is a record for review, not courtroom proof. The method page lists every limit and the benchmark has the figures.

Sources and further reading: CIPA DC-008-2019, Exif 2.32 specification (DateTimeOriginal, DateTimeDigitized, DateTime, and the GPS tags); C2PA Technical Specification 2.3; RFC 3161, Internet X.509 Public Key Infrastructure Time-Stamp Protocol; Google Photos Help: download photos or videos to your device.