Free · runs in your browser
How to read the traces a camera original and a re-saved copy leave behind, how to preserve a file properly, and where metadata analysis stops being reliable.
Metadata can often show whether a video is a camera original or a copy that has been re-saved, trimmed or edited: dates that disagree, an editing app’s name in the encoder field, missing camera data, and a bitrate or key-frame pattern that no camera produces. It cannot prove that what the video shows is genuine, and it cannot prove a file is untouched, because every one of those fields can be rewritten.
Treat this page as a first look, not an expert report. Evidence for a court, an insurer or a disciplinary hearing needs a documented chain of custody, hashes recorded when the file was first collected, validated tools and a qualified examiner. Nothing on this site, including this guide, provides that.
For the first look, you can open a file here and read it without uploading it. Report gives the full MediaInfo text and the MP4/MOV box tree, Date & time lines up every date in the file and flags ones that disagree, Provenance shows Content Credentials and encoder tags, and Calculate hashes gives MD5, SHA-1 and SHA-256 fingerprints.
These steps use built-in commands and ffprobe; the same information is in the browser report if you prefer.
Keep the file exactly as received, work on a copy, and record its SHA-256: certutil -hashfile clip.mp4 SHA256 on Windows, shasum -a 256 clip.mp4 on a Mac, sha256sum clip.mp4 on Linux. Write down where and when you got it.
Save a full report (ffprobe -v error -show_format -show_streams -of json clip.mp4, or Download JSON here). Note the container brand, every track, and every tag, before you change anything.
List the creation date in the movie header, the track dates, any maker key such as Apple’s creationdate with its time zone, and the file system dates. Look for disagreements and default values such as 1904 or 1970.
Read the encoder and software tags and the make and model. An editor’s name, or a converter library, means the file was re-saved; device data that does not fit the claimed camera is a question to ask.
Compare the codec, bitrate, key-frame spacing and audio format with what the claimed device records, and read any Content Credentials history. Then write up what you found and what you could not determine.
The most useful question metadata can answer is whether you have the first file a device wrote or a later generation. Camera originals tend to be rich and consistent; re-saved copies tend to be thinner and carry the fingerprints of whatever wrote them last. The table shows typical patterns. They vary by device and app, so compare against a known original from the same model whenever you can.
| What to check | Typical camera original | Typical re-saved or edited copy |
|---|---|---|
| Container brand | The camera’s usual brand (an iPhone writes QuickTime qt) | Whatever the editor or platform writes, often isom or mp42 |
| Software / encoder tag | The phone’s OS or the camera’s firmware version | An editing app, a converter, or a library such as Lavf |
| Device data | Make, model, lens, sometimes a serial-style id | Missing, or left over from the source with nothing new |
| Location | Present if location was on | Usually gone after messaging apps and platforms |
| Dates | Movie, track and maker dates agree to the second | A new encoded date, zeroed dates, or dates that disagree |
| Extra tracks | Timecode, telemetry or maker data tracks | Video and audio only |
| Bitrate | High and fairly steady for the resolution | Lower, shaped by the platform’s or editor’s settings |
| Key frames | A regular interval the camera uses | A different interval, or key frames at scene cuts |
A single MP4 or MOV can hold half a dozen dates, and they mean different things. Disagreements between them are often the clearest sign that software rewrote the file.
| Date | Where it lives | What it usually means |
|---|---|---|
| Movie created / modified | mvhd box, UTC | When the file was written; editors usually set it to the export time |
| Track created / modified | tkhd and mdhd boxes, UTC | Normally the same as the movie dates on a camera original |
| Apple creation date | com.apple.quicktime.creationdate, with time zone | The local recording time on iPhone and other Apple devices |
| Tagged or encoded date | Tags written by apps | Depends on the app; often the export time |
| File system created / modified | Your computer, not the file | When that copy arrived on the disk; changes on every copy |
The change video date tool is a reminder of how easy these fields are to set: any of them can be typed in, on this site or with ffmpeg. That is why dates can support a story but never prove one on their own.
Re-encoding leaves marks in the streams themselves, not just the tags. They show that a file has been through an encoder again; they do not show what, if anything, was changed in the picture.
ffprobe -v error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=p=0 clip.mp4
Lines whose flags start with K are key frames. Regular spacing suggests one continuous encode; an irregular stretch is worth a closer look at the picture in that part of the clip.
When a file carries Content Credentials, the manifest can list what was done to it (opened, edited, cropped, converted) and the earlier files it was built from. It is the only kind of metadata designed to resist tampering, because each step is signed and the media is hashed.
The Content Credentials viewer reads and explains the history. It does not verify signatures, so confirm them at contentcredentials.org/verify before relying on what the history says. And remember the limits: an app that does not support C2PA can drop the manifest entirely, leaving a file with no history at all.
Everything on this page is a first look. It is not court-grade analysis, it is not peer-reviewed, and it should not be presented as expert evidence.
If the stakes are high, preserve the original file and its hash, write down how you obtained it, and speak to a qualified examiner before you edit, convert or re-share anything. For a broader judgement on whether a clip is synthetic, see is this video AI?
It can show a file was re-saved by software, for example through an editor’s name in the encoder tag or a new encoded date. It cannot show what was changed in the picture, or prove that nothing was, because the same traces appear when a file is only converted or uploaded.
Yes, easily. Dates, device names, locations and software tags can all be set with free tools. Signed Content Credentials are the exception: they can be stripped, but a valid signature cannot be forged without the signer’s private key.
No. Court evidence needs a documented chain of custody, validated tools and a qualified examiner who can testify about the method. Use what you find here to decide whether to ask a professional, not instead of one.
Compare the duration with what the source claims, look at the movie and track dates, and check whether the first frame is a key frame where the camera would not put one. A trim done by stream copy may leave the codec settings unchanged, so the signs can be slight.
In the file itself: the device make and model, recording date and time zone, location and software tags, if they survived. Overview sums them up in one sentence. If they are missing, the file was probably shared through an app that strips them, and the original has to be requested from whoever recorded it.
No. The file is read, not written, and the hash stays the same. Edits only ever produce a new file when you press Download new file; the original on your device is untouched.
Any change to any byte changes the hash, including a renamed tag, a stripped location or a remux that leaves the picture identical. Different hashes mean different files, not necessarily different content.