Timestamped photo, defined: a photograph carrying a record of when it was taken or received, whose evidential value depends on whose clock set the time and whether the file has changed since.
A timestamped photo is a photograph with a record of when it was captured. That record can live in three places: printed onto the image by a camera app, written into the file's metadata by the phone, or logged by the server of the organisation that received it. The word timestamp covers all three, and for a photo used as evidence the differences between them are the whole subject.
The definition matters because a date in the corner of a picture is the first thing a claimant, a tenant or a contractor points to, and the first thing an adjudicator discounts.
Device clock versus trusted server time
Every timestamp comes from a clock, and the question is who controls it:
- Visible stamp: drawn on the pixels by a stamp-camera app. The app reads the phone's clock, and most stamp apps let the user set the date and time by hand or stamp an older photo from the gallery. It is text, and it proves that text was added.
- Metadata timestamp: the capture time the phone writes into the file's EXIF data. Set by the device clock, which the owner can change in settings. Editable with free tools, and stripped entirely by most messaging apps.
- Server receipt time: the moment the receiving organisation's system logged the file arriving. Set by a clock the submitter does not control. It proves the photo existed no later than that moment.
Only the third is independent of the person who took the photo. The first two are useful context and are not proof of time.
The four questions a reviewer asks
Before relying on a timestamped photo, a claims handler, deposit adjudicator or tribunal will want answers to four questions. Is it authentic: was this taken by a camera at a real scene, or generated, screenshotted or re-photographed? Is it intact: is the file the same as when it was created, or has it been edited, re-saved or cropped? What is the time source: which clock set the timestamp, and could the submitter change it? What is the custody: who has held the file since capture, and can each handover be shown? A digital fingerprint taken on receipt answers the second, a server clock answers the third, and a logged chain of custody answers the fourth. The first is the hardest and is where recording inside a controlled session, rather than uploading an existing file, does most of the work.
Timestamped photo example: a scuffed bumper on a returned hire van
A hire desk finds a scuffed rear bumper on a van at return. The customer says the damage was there at collection and sends a photo with a date and time printed in the corner that matches the collection morning. The date was written by the customer's phone, which the customer controls, so it settles nothing on its own.
The desk's own pre-hire record was captured through a guided link at the counter: four corners, the rear bumper close-up, the mileage. Each file was hashed on arrival and the receipt time was logged by the server. The bumper is clean in that record, the receipt time is forty minutes before the customer's stamp, and the files are unchanged since. The desk can now show a timeline that does not rely on anyone's phone clock, and the customer's photo is weighed accordingly.
What a timestamped photo does not do, and the mistakes teams make
It does not prove when the event happened. A photo of damage taken on Tuesday proves the damage existed by Tuesday, not that it occurred on Tuesday.
It does not prove the photo is of the thing claimed. Time and subject are separate questions.
It does not survive forwarding intact. A photo sent through a messaging app arrives re-compressed and usually with its metadata removed, so "the EXIF says Tuesday" is a claim the reviewer can no longer check.
The recurring mistakes: reading the corner date as verification; comparing a device timestamp in one time zone with a server time in another; accepting a screenshot, which carries the screenshot's time and nothing from the original; not keeping the original file, so the hash can never be checked; and never recording who touched the file between capture and review. For claims work, the evidence standards are set out in insurance claim documentation.
Where the record goes
The original file, its provenance information, the server receipt time, the hash taken on arrival and the reviewer's notes should sit together on the case, and the case should be the thing that is disclosed, not an image pulled out of a chat thread.
Venta Capture, a product of VentaVid, sets the time on the receiving side: the participant is sent a link, follows guided steps in the mobile browser with no app, records in the session, and the submission arrives with a server-verified receipt time, a fingerprint per file and a sealed timeline for the reviewer. File metadata from the device is shown too, labelled as unverified. More at the Venta Capture pages.
In practice: see how insurers use Venta Capture for remote claim inspection.