What the Camera Records Proves Nothing
Every photograph carries dates: the capture time in the EXIF data, the file system's creation and modification times, sometimes a date burned into the file name. None of them is proof. The camera clock is set in a menu and can show any year you like. EXIF fields can be rewritten with free tools in seconds, and our guide on what metadata can and cannot prove walks through how little survives scrutiny. File system dates change every time a file is copied, and can also be set directly.
This matters the moment a date is contested. An insurance claim needs photos from before the storm, not after. A dispute over a property's condition turns on when the pictures were taken. And since generative models became good, a new version of the question appears in every context: can you show this image existed before it could have been fabricated for the dispute? A date that rests on the camera's own records answers none of this.
The Claim You Can Actually Prove
Cryptography cannot prove when a photo was taken. What it can prove is narrower and still decisive: that a photo existed, in exactly its current state, no later than a certain date. The technical term is proof of existence.
The mechanism has two parts. First, the file is hashed. A cryptographic hash is a short fingerprint with the property that any change to the file, a single pixel, a single metadata byte, produces a different fingerprint. Second, the fingerprint is fixed in time by someone other than you. Once an independent party has recorded the hash on a known date, the file that matches it demonstrably existed by then, because the hash could not have been computed from a file that did not exist yet.
Note what this does not require: the photo itself never has to leave your hands. The hash reveals nothing about the image contents. Everything that follows works on fingerprints.
The Methods, Weakest to Strongest
Emailing the file to yourself is the folk method, a digital version of the old envelope trick. It is weak. Mail headers can be forged, mailbox contents can be altered by whoever controls the mailbox, and the party vouching for the date is essentially you. It may persuade an uninterested party; it will not survive an expert.
Publishing the hash somewhere public is better. Posting a hash on a widely archived public platform creates witnesses. The weaknesses are practical: platforms delete content, archives have gaps, and you will need to explain the whole construction from scratch to whoever evaluates it.
A notary works and is well understood by courts. The drawbacks are cost and friction. Notarizing every shoot is not realistic for working photographers, so in practice notarization happens late, after a dispute exists, which is exactly when the early dates are no longer provable.
Blockchain anchoring embeds the hash in a public ledger whose blocks carry dates that no single party controls. Technically this is strong. The practical burden is interpretation: the party checking your proof must be walked through what a blockchain is, why block times are trustworthy, and how your hash relates to a transaction. Doable, but you carry the explanation.
A trusted timestamp authority is the method built for this purpose. It is standardized as RFC 3161, the same mechanism that backs signatures in PDF workflows and code signing, so the infrastructure and the legal understanding both exist. The authority signs your hash together with the current time, and that signed statement can be verified with standard tools by anyone, indefinitely.
How a Trusted Timestamp Works
The protocol is short. You compute the hash of your file and send only the hash to the timestamp authority. The authority appends the current time from its audited clock, signs the combination with its private key, and returns the signed token. That token is the proof: anyone holding the file, the token and the authority's public certificate can verify that this exact file's hash was seen by the authority at that time.
Three properties make this hold up. The authority never sees your photo, only the fingerprint, so nothing confidential leaves you. The date comes from a third party whose business is operating an accurate, audited clock, not from any party to the dispute. And verification is mechanical: it does not require trusting the photographer, the platform that arranged the timestamp, or anyone's memory.
Timestamping a Whole Shoot at Once
Timestamping files one by one does not fit real photographic work. A single day of shooting produces hundreds or thousands of files, and the moment worth proving is the earliest one available, right after the shoot.
There is already a document in your workflow that covers every file at once. When a card is backed up with a professional transfer tool, the tool writes a manifest: a list of every file on the card with its checksum. Timestamping that one manifest fixes the fingerprint of every frame on the card in a single operation.
This is what Lumethic Offloads automates. You upload the manifest your offload tool wrote, Lumethic signs it and has it countersigned by an independent timestamp authority under RFC 3161, and the receipt states that every file on the card existed, exactly as it is, no later than that day. The receipt is self-contained and verifies on a public receipt checker without an account, so the other side of a dispute can check it themselves. One receipt covers the whole card, which is why proving dates for everything you shoot is realistic rather than theoretical.
For the receipt to bind file contents rather than only the backup event, the transfer tool's checksum setting matters; the checksum settings guide covers the one change to make.
The Gap That Remains
Proof of existence gives you "no later than". It cannot give you "no earlier than", and it says nothing about what the photograph shows. A timestamp on a manipulated image proves the manipulated image existed by that date, nothing more.
Both gaps have established answers. The taken-on date is supported the traditional way, by a camera clock that was set correctly, field notes whose times match the files, and the photographer's testimony; the camera setup checklist for evidence work covers that discipline. Whether an image is an unedited camera original is a separate forensic question, answered by RAW verification. Combined, the pieces close the timeline from both ends: authentic capture, on the card and anchored by the shoot date, verified unchanged when it mattered. That combination is the working chain of custody described in our legal evidence workflow.
Proof of Date FAQ
Can EXIF data ever serve as proof of date? As supporting context, yes; as proof, no. EXIF times that are consistent with anchored dates, field notes and testimony strengthen the overall record. On their own they can be set to any value.
Does a timestamp reveal my photo to anyone? No. Only the hash is sent and stored. The hash cannot be reversed into the image, and holding the hash without the file proves nothing about the file's contents.
What if the timestamp service shuts down later? An RFC 3161 token verifies against the authority's certificate with standard cryptographic tools. Lumethic receipts are additionally self-contained JSON, built to be checkable independent of Lumethic. Keep the receipt with your project documentation like any other record.
Is a screenshot with a visible date worth anything? No. Screenshots inherit every weakness of the files they show, and add their own. A date visible in an image is just pixels.
How soon after the shoot should the timestamp happen? As soon as possible, because the anchor date is the earliest date you can ever prove. Anchoring the offload manifest right after the card backup makes the provable date the shoot date itself.
