---
title: "Video Forensics: Was This Video Edited? | metadata.video"
description: "Video forensics with metadata: dates, encoder tags, re-encoding signs and C2PA history that show a file was edited or re-saved, and what they can’t prove. Free."
url: https://metadata.video/video-forensics
---

Free · runs in your browser

# Video forensics: what metadata can show about editing

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.

## A careful first look at a video file

These steps use built-in commands and ffprobe; the same information is in the browser report if you prefer.

1. ### Preserve the file and hash it
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.
2. ### Record the structure
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.
3. ### Compare the dates
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.
4. ### Check the writing software and the device
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.
5. ### Look at the streams and the provenance
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.

## Camera original or re-saved copy?

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.

__Patterns, not rules. A difference is a reason to ask questions, not a conclusion.__
| 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          |

The layers of a video file. Re-saving usually keeps the outer container and the streams but rewrites or drops the device, location and provenance layers.

## Reading the dates

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.

__The dates the Date & time section lines up on a single timeline.__
| 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            |

* **1 January 1904 at midnight** is the zero point of MP4 and MOV dates: the field was never set or was wiped.
* **1 January 1970** is the Unix zero point, and **1 January 2001** Apple’s reference date; both show up when software writes a zero or a default.
* A recording date in the future, or after the date the file was supposedly received, is a strong sign the clock or the tag was wrong or changed.
* Dates an hour or two apart usually reflect UTC versus local time, not tampering. Check the time zone before reading anything into it.

The [change video date tool](https://metadata.video/change-video-date) 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.

## Signs of re-encoding

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.

A group of pictures: a key frame (I) followed by predicted frames (P and B). Cameras use a fixed spacing; editors and platforms often use their own, and add key frames at cuts.

* **Key-frame spacing.** **Video** shows the GOP length. A change in the pattern part-way through can mark a spliced section, but encoders also add key frames at scene changes on their own.
* **Bitrate over time.** The bitrate graph in **Video** shows where data is spent. Platform copies usually have a lower, capped bitrate compared with the camera’s; see [the bitrate checker](https://metadata.video/video-bitrate-checker).
* **Codec change.** A clip that the claimed phone would record in HEVC but arrives in H.264 or AV1 has been converted somewhere; the [codec checker](https://metadata.video/video-codec-checker) shows which.
* **Size and frame rate.** Platform ladders produce typical sizes and bitrates. A “4K original” at a platform’s 1080p size is a copy.
* **Audio.** A resampled or re-encoded audio track, or one that is missing, is another sign of a second pass.

Constant versus variable bitrate. Camera files and platform copies tend to have different bitrate shapes, which the bitrate graph makes visible.

### Checking key frames with ffprobe

              `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.

## Edit history in Content Credentials

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.

A Content Credentials chain: each supporting app that touches the file adds a signed record and points back to the version it started from.

The [Content Credentials viewer](https://metadata.video/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.

## Limits, and what professionals add

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.

* **Metadata is editable.** Dates, device names, locations and software tags can all be changed with free tools, including this site’s own editor. A clean, consistent set of tags is what a careful forger would produce.
* **Absence proves nothing.** Missing fields usually mean the file went through a messaging app or a platform, which describes most videos people share.
* **A re-encode is not a fake.** Almost every shared video has been re-encoded. Signs of re-saving tell you the file is not the original, not that the content was manipulated.
* **Stream-copy edits leave few traces.** A trim made with a stream copy can keep the original codec settings, so the cut may only show in the dates and the duration.

### What a professional examination adds

1. Collection with a documented chain of custody and hashes taken at the moment of collection, ideally from the original device.
2. Comparison against reference files from the same make, model and firmware.
3. Analysis of the picture and sound themselves: sensor noise patterns, compression artefacts, frame-level double compression, electrical network frequency in the audio, lighting and shadow geometry.
4. Validated, documented tools and methods, following published best practice from bodies such as the Scientific Working Group on Digital Evidence (SWGDE).
5. A written report by an examiner who can explain and defend the method.

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?](https://metadata.video/is-this-video-ai)

## Video forensics: common questions

### Can metadata prove a video was edited?

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.

### Can video metadata be faked?

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.

### Is this analysis good enough for court?

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.

### How can I tell if a video has been trimmed?

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.

### Where can I find the original source information of a video?

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.

### Does opening a file here change 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.

### Why do two copies of the same video have different hashes?

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.

## Related metadata guides

* [ Video metadata viewer See, explain, edit and remove everything a video or photo says about itself. ](https://metadata.video/)
* [ Full video file info report A MediaInfo-style text report, JSON and box tree for any video, with hashes on request. ](https://metadata.video/video-file-info)
* [ Content Credentials (C2PA) viewer Read a file’s C2PA manifest: claim generator, actions, AI assertions, ingredients and signer. ](https://metadata.video/content-credentials-viewer)
* [ How to tell if a video is AI-generated Provenance, watermarks, metadata, visual tells and sources: what each check can prove. ](https://metadata.video/is-this-video-ai)
* [ Check and change a video’s date See when a video was recorded and fix wrong dates, time zones and 1970 defaults. ](https://metadata.video/change-video-date)
* [ How to use ffprobe Real ffprobe commands for streams, tags, HDR and frame counts, and ffmpeg for stripping. ](https://metadata.video/how-to-use-ffprobe)
* [ Find where a video was taken Read a video’s GPS location and see it on a map, with altitude, accuracy and country. ](https://metadata.video/where-was-this-video-taken)