Photo verification: how to verify a customer-submitted photo

This post in 30 seconds.

• The order: control how the photo is made, then read the file and your own receipt record, and only then check the finished file for AI traces, internet matches and earlier submissions.
• The rule: the time inside a file is a claim by the phone. The time your server received it is a fact. A seal shows whether anything changed afterwards.
• Who this is for: claims handlers and claims operations leads, returns and warranty managers, lettings and property managers.

To verify a customer-submitted photo, work in three layers and keep them in this order. First, control how the photo is made: have it recorded in a session you issued instead of picked from the gallery. Second, read what the file and your own receipt record can tell you. Third, and last, check the finished file for AI traces, run a reverse image search and compare it with earlier submissions.

Most teams do it backwards. A photo lands in the inbox, something looks off, and someone opens a detector. By then the strongest check is gone, because it had to happen while the photo was being taken.

We build Venta Capture, VentaVid's guided capture platform, for teams that decide on photos and video they did not take themselves: a claim, a return, a deposit. If you want to see what a session recording looks like on the receiving side before you read on, start for free and send a link to your own phone.

What does photo verification mean when the photo comes from a customer?

It means answering four questions about a photo before you rely on it:

1. When was it taken?
2. Where was it taken?
3. How did it come to exist: recorded for this case, or picked from somewhere?
4. Has it changed since it was taken or received?

It goes by several names. Image authentication is the broad term, metadata verification covers the data attached to the file, and photo manipulation detection covers signs of editing.

There is a fifth question, and no tool answers it: does the photo show what the customer says it shows? A photo can be recorded today, at the right address, untouched, and still show damage that was there before the policy started. Verification tells you how far you can rely on the file. The decision about the case stays with you.

Layer 1: can you control how the photo is made?

This is the strongest layer, and it only exists before the photo does.

A photo that a customer picks from the gallery has a history you cannot see. It was taken at some point, maybe cropped, maybe forwarded by a partner, maybe downloaded. None of that has to be dishonest. You just cannot tell. The glossary entry on upload versus capture walks through both routes.

A photo recorded in a session you issued has a short history. You sent a link, the customer opened it on their phone, the camera opened inside that page, and the photo went from the camera to your server. That changes what you can say afterwards:

• The moment. The recording happened between the link being opened and the file arriving.
• The route. The file did not pass through a photo app or a chat.
• The instruction. You decided what had to be in frame: the whole item, the label, the wider room.

Two details make or break this layer.

The first: a "take a photo" button on an ordinary upload page is not session capture. The standard browser attribute behind that button is a request, and MDN's documentation says so. It "specifies that, optionally, a new file should be captured", and on a desktop "you'll likely get a typical file picker". If your upload page relies on that attribute alone, some of your "camera" photos are gallery files.

The second: some customers have a good reason to upload. The burglary was last night and the photo was taken then. Allow it where the case calls for it, and label it as an upload. Mixing both kinds without a label is what hurts.

What can capture in a mobile browser establish, and what can it not?

Running in the browser means the customer installs nothing. It also sets limits, and you should know them before an ombudsman asks.

In Venta Capture those session checks are switched on per customer: a spoken code issued for that session, a changing session code in the frame of every photo and video, a motion step that compares the phone's movement sensor with the movement in the image, and a device consistency check. Each one produces an observation for a reviewer. Harder to manipulate does not mean impossible to deceive.

Layer 2: what can the file and the receipt tell you?

Once a photo is in, ask of every piece of information about it: whose statement is this?

The data inside the file is EXIF data, part of the wider metadata a phone writes. It is worth reading. It is also easy to change. ExifTool, a free and widely used utility, describes itself as an application "for reading, writing and editing meta information", and lists shifting date and time values among its features. Photographers use it to fix a camera clock. It also means a date in a file is only as good as the person holding the file.

Missing metadata is weaker evidence still, in either direction. Messaging apps commonly re-save a photo on the way through. An iPhone lets the owner switch off location in the share options before sending. A customer who does either has done nothing wrong, so advice that calls empty metadata suspicious sets you up for a false alarm.

How do you prove when a photo was taken?

From the file alone, you can't. You can establish two other things, and together they usually do the job.

You can establish when you received it. That time sits on your server, out of the customer's reach. If the photo was recorded in a session, receipt normally follows the recording closely. If it was uploaded, receipt tells you the photo existed by then, and nothing about how long before.

You can also establish that the file has not changed since. On receipt, a digital fingerprint is calculated for each file and the case is sealed. Change one pixel later and the fingerprint no longer matches, which is what tamper evident means in practice. For the time itself, a timestamp from an independent timestamping authority adds a party that is neither you nor the customer. The standard behind it, RFC 3161, puts the scope in one line: such a service "supports assertions of proof that a datum existed before a particular time". It says nothing about when the hail fell.

A timestamped photo with a date printed in the corner is a different thing. Any app can print a date. It only carries weight when the system that received the photo put it there. The same problem for inspection records is covered in photo evidence for inspections.

Layer 3: how do you check a photo that already exists?

This is the layer everyone knows, and it belongs last. You use it for the photos you could not control: the upload from the night of the burglary, the picture that came by email.

Three checks are worth running on an uploaded photo.

• Earlier submissions. Has this photo, or one that closely resembles it, come in before? Only you can run this check, because only you hold your earlier cases. A match is concrete: two cases, one image.
• Internet matches. A reverse image search looks for the picture online. Google's help page says results can include "Websites with the image or a similar image". A hit on a marketplace listing or a stock site is a strong reason to ask questions. No hit means little: most photos on people's phones were never published.
• AI traces and editing traces. Software looks for the patterns that generated or altered images tend to carry. Treat the result as a pointer. Generators keep changing, and a re-saved or compressed file can lose the traces. NIST's overview of synthetic content treats detection as one approach next to provenance tracking and labelling, which is the right way to file it.

How do you check if a photo has been edited?

Four things are worth a look, and none needs a forensic lab.

1. Software named in the metadata, or a capture time and a save time that disagree. A messaging app re-saving a file is not an edit.
2. Location that was added or changed later. A position fix that is dated differently from the photo, or location data with no camera data beside it.
3. Screenshots and photos of screens. A screenshot has lost its history. A photo of a screen is a screen recapture, and it gives the file a fresh, clean-looking record.
4. The picture itself. Shadows that disagree, a repeated texture, a plate or label that is sharper than the panel around it. The glossary entry on image forensics lists the techniques behind the tools.

If the only copy you have came through email or chat, ask for the original file. Better still, ask for a new recording.

What should you do with a finding?

A finding is a reason to look. It is never the decision.

Every check above has an innocent explanation. Several attempts at a photo is what careful people do. A device seen on an earlier case can be a shared family phone. Our post on fraud red flags for claims handlers pairs each flag with its innocent twin.

So write down what a reviewer does next, per kind of finding:

• Nothing unusual: decide the case on its content.
• Something to look at: ask for a new recording of the same item, in a session, with one specific instruction (the serial number, the wider room, the other side). Most cases end here.
• Something that cannot be explained: hand it to a second person, and record who looked and what they concluded.

A law firm that advises insurers made the same point in January 2026. After listing techniques against AI-generated claim photos, Debevoise's data blog warned that insurers "should take care not to overcorrect and either significantly slow down or wrongly deny legitimate claims".

If your reviewers decide on uploads today and you want to see the same case arrive as a sealed session recording, book a demo and bring one real case type.

A photo verification routine you can write down this week

It fits on one page, and it works with or without software.

1. Pick the case types where the photo carries the decision. A total loss, a return above a set value, a deposit deduction. Leave the rest alone.
2. Write the minimum evidence set for each. Wide shot, close-up, identifier, one thing for scale.
3. Decide per case type: session recording only, or upload allowed. A cracked screen can be recorded now. Sunday's storm may need Sunday's photo.
4. Record receipt time yourself and keep the original file. Do not rename, resize or forward it through a chat.
5. Label every upload as an upload, run the three checks from layer 3, and read the file's metadata as a claim.
6. Write the three reviewer actions from the section above into the procedure, including who the second person is.

What the identifier is depends on your desk:

• Claims: number plate or VIN for motor, the room and the source of the damage for property. Our guide to photo evidence for insurance claims has the shot list.
• Returns and warranty: the serial number and the defect in one frame, for a warranty claim or in returns management.
• Lettings: the room, the fixture and something that places it in the flat. The same photos later feed the deposit dispute evidence.

Where does Venta Capture fit, and where does it not?

Venta Capture covers layers 1 and 2 by design and treats layer 3 as the labelled fallback.

You send a secure capture link. The customer opens it in the mobile browser, with no app and no account, and follows the steps you wrote. Per workflow you set whether only recording in the session is allowed, or an upload from the gallery as well.

In the case, a photo recorded in the session carries a visible stamp with date, time and seal. An upload never gets that stamp. It is marked "Provenance: Not verified" and checked separately: on its metadata, on AI traces, on whether it already exists on the internet, and on whether it resembles an earlier submission. Each finding comes with its caveat in plain language.

The whole case is sealed on receipt: a fingerprint per file, a signed seal, a timestamp from an independent timestamping authority and a printable proof of seal. With the session record, that adds up to more than 25 control points per submission, and a reviewer marks each deviation as handled or as a genuine deviation, with name and time.

Where it does not fit:

• Photos you already hold. It records new submissions.
• Cases that need a specialist on site. Hidden moisture, structural damage, a disputed cause.
• A verdict. It measures and records. It does not say whether a customer is honest.

The use case pages go further per desk: remote claim inspection, customer support and returns and property.

Frequently asked questions

What is photo verification?

Photo verification is checking how far you can rely on a photo before you decide on it: when it was taken or received, where, how it came to exist, and whether it changed afterwards. For customer-submitted photos the strongest version is controlling the capture itself.

Can you tell from EXIF data when a photo was taken?

You can read the time the phone wrote into the file. It comes from the phone's own clock and can be changed with free tools, so treat it as a claim. It gains weight when it agrees with the time your server received the file.

Does missing metadata mean a photo is fake?

No. Messaging apps commonly re-save photos and drop the data, and a phone can share a photo without its location. An empty file tells you the photo took a detour. Ask for the original, or for a new recording.

Can software tell whether a photo is AI-generated?

It can point at traces that generated images tend to carry, which is a reason to look closer. It cannot give certainty in either direction, because generators change and re-saving a file can remove traces. Let a person decide.

Does the customer need an app for a verified capture?

Not with a link-based capture. The customer opens the link in the phone's browser and records there. The trade-off is that a web page sees less of the device than an installed app, which is why the session checks and the server's receipt record carry the weight.

Start with one case type

Pick the case type where a photo decides the most money, and change only how that photo is made. When the customer records it in a session, layers 1 and 2 are done before anyone opens the case.

You can set that up on the free plan, with no credit card: start for free and send the first link to your own phone. Or book a demo, and we will build the workflow for your case type on the call.