How to Check Video Metadata: Authenticity Guide 2026
A video lands in your inbox ten minutes before publication. The sender claims it shows a public official taking cash. The clip looks plausible. The lighting is believable. The audio sounds clean enough. That's exactly when people get burned.
If you only judge the image on screen, you're letting the file tell its own story without checking its paperwork. In forensic work, the first question isn't whether the scene looks real. It's whether the file's hidden record supports the claim attached to it.
That means you need to check video metadata before you quote it, air it, archive it as evidence, or send it to counsel. Metadata won't answer everything. It can be edited, stripped, or falsified. But it often gives you the fastest first read on where a file came from, what touched it, and whether its story holds together.
Why Metadata Is Your First Clue to Video Authenticity
A disputed video rarely arrives with clean provenance. It arrives through Signal, email, AirDrop, or a hurried handoff from a source who says the clip is urgent and original. In that moment, the initial impulse in many newsrooms and legal teams is to watch the footage and judge whether the scene looks believable. That is useful later. The first forensic check is whether the file's recorded history matches the claim attached to it.
Metadata gives the earliest technical clues about origin, handling, and export history. On a genuine camera-original file, that history may include device identifiers, timestamps, rotation or orientation values, geolocation, codec settings, and software tags. On a file that has been reprocessed, stripped, or deliberately repackaged, those fields often change, disappear, or stop making sense together.
That matters in AI and deepfake cases. One of the simplest ways to hide a synthetic or edited video is to remove metadata entirely, then redistribute the file as if it came straight from a phone or platform upload. Stripping metadata does not prove deception. Many social apps and editing workflows remove it automatically. But in practice, the absence of expected fields is often the first sign that someone wanted to break the chain between the file and its true source.
A claimed eyewitness clip should leave a footprint consistent with how it was captured and moved. A phone recording may show device make, creation time, and orientation behavior that fits handheld capture. A camera-original file may preserve a fuller technical record. A re-exported clip often shows software involvement, new timestamps, or encoding settings that point to post-processing. The useful question is not whether metadata exists. It is whether the metadata fits the story.
Practical rule: Use metadata as an early screening tool. It helps you decide whether the file should be treated as likely original, clearly processed, or suspicious enough to preserve for deeper examination.
I have seen teams spend an hour arguing about visual artifacts while missing the simpler contradiction in the file record. If a source says a clip is straight off an iPhone, but the metadata shows Adobe Media Encoder, missing creation tags, and a new container timestamp, the issue is no longer just what appears on screen. The issue is whether the source description is false, incomplete, or carefully framed to hide editing.
For journalists, this belongs inside a broader practical workflow for fact-checking videos. When attribution is part of the question, a separate source video finder workflow can help establish whether the file is an older clip being recirculated under a new claim.
What metadata does well
Metadata is strongest when you use it to answer four practical questions:
- Who created or processed the file through device, creator, or software fields
- When the file was created, modified, or exported through timestamp patterns
- Where capture may have occurred through GPS or location-related tags
- How the file was built through container, codec, bitrate, frame rate, and stream details
What metadata does not do
Metadata does not prove authenticity by itself. Real footage can pass through editing software for innocent reasons. Fabricated footage can be wrapped in believable tags, especially when someone copies metadata from another file or rewrites fields with command-line tools. The value is in inconsistency, omission, and context. When the source claim, the platform history, and the file record do not line up, that is the point where a routine check becomes a forensic problem.
Quick Methods for a First-Pass Metadata Check
A reporter gets a video by text, with a claim that it was shot minutes ago on a witness's phone. Before anyone writes a caption or sends it to counsel, do a fast metadata triage on the original file. The goal is simple: find out whether the file behaves like a fresh camera original, a routine export, or something that has been processed, stripped, or rebuilt to hide its origin.
Use built-in operating system views
Start with what the machine already shows. On Windows, right-click the file and open Properties, then review General and Details. On macOS, use Get Info. These views give a quick read on file size, dates, duration, dimensions, and sometimes frame rate or codec.
For a first pass, check three things in particular:
- Dates that fit or conflict with the claim. A “just captured” file with an older creation or modification pattern needs explanation.
- Filename and extension behavior. Native camera files usually follow recognizable naming conventions. A manually renamed file or an unexpected container can indicate reposting, editing, or export from another tool.
- Whether the metadata feels too thin. A file that claims to be straight from a phone but shows almost no descriptive detail deserves closer review.
These screens are useful because they are fast. They are also easy to misread. Operating systems often display filesystem dates rather than original capture timestamps, and those dates change when a file is copied, downloaded, or moved between devices.
Know what quick checks can and cannot tell you
A shallow metadata view helps sort routine files from suspicious ones. It does not tell you whether a video is authentic.
That distinction matters in deepfake and synthetic-video cases. Deliberate stripping is common. Someone can remove device and software traces, rewrap the video in a common MP4 container, and leave behind a file that looks ordinary in Finder or Windows Properties. In practice, that absence can be as informative as a bad tag, especially when the source story depends on the file being a direct camera original.
I treat OS-level review as intake, not conclusion.
Use online tools carefully
Browser-based viewers can help when you are on a locked-down system or need a quick look from a borrowed machine. They are best reserved for low-sensitivity material. If a clip may become evidence, expose a confidential source, or contain personal data, keep it off third-party upload tools unless policy and counsel allow it.
When you do use a web viewer, read beyond the obvious labels. Focus on container format, codec, stream layout, duration, and any software or encoder traces. Missing fields matter too. A file that should carry ordinary capture context but arrives nearly blank may have been intentionally sanitized.
Teams that handle disputed footage regularly should standardize this step with forensic video analysis software rather than relying on ad hoc browser checks.
Browser and platform checks
If the video only exists on a platform, the first-pass job changes. You are no longer examining the source file itself. You are checking platform-side chronology, upload context, and whether the public version matches the story attached to it.
For YouTube-hosted material, metadata viewers that query platform data can help establish upload timing, visibility status, thumbnails, and other publication clues through the referenced YouTube material. That does not replace file-level analysis. It helps answer a different question: what the platform received and displayed.
When to stop using quick methods
Escalate fast if any of the following appear:
- The claim has legal, reputational, or public-safety consequences.
- The source description conflicts with the file's dates, name, or format.
- Expected metadata is missing without a clear reason.
- The file shows signs of export or recompression.
- The context suggests possible AI generation, deepfake editing, or deliberate metadata stripping.
Quick checks help you sort incoming files and identify obvious inconsistencies. They do not settle contested authenticity, and they are not strong enough for a conclusion you may need to defend later.
Command-Line Tools for Deep Metadata Forensics
A disputed video lands in a newsroom inbox an hour before publication. The sender says it is an untouched phone recording. The file opens cleanly, plays normally, and carries very little visible metadata. That is a common pattern in manipulated or AI-assisted material, because stripping metadata is often the first cleanup step after generation or editing. Command-line tools help test whether the file's structure still preserves traces of what happened.
Start with FFprobe
FFprobe should be part of the standard workflow for any team that may need to explain its findings later. It reads the container and stream structure directly, which makes it useful for spotting export artifacts, codec mismatches, and signs that a file passed through editing or synthesis software before it reached you.
Use:
ffprobe -v quiet -print_format json -show_format -show_streams input.mp4
A practical overview from Neurohive's FFprobe walkthrough shows the kind of output this produces. Expect format-level fields such as duration, bit rate, and container details, plus stream-level fields such as codec, frame size, frame rate, and audio characteristics.
The main value is comparison between the claim and the file. A video described as a straight phone original should usually resemble files produced by that phone model. If FFprobe shows a generic export profile, unusual handler tags, or stream settings more consistent with editing software than native capture, the file needs closer review.
What to inspect in the FFprobe output
Start with the fields that reveal production history fastest.
| Field area | What it tells you | Why it matters |
|---|---|---|
| format_name | Container type | Should fit the claimed capture or transfer path |
| bit_rate | Overall encoding profile | Sudden normalization can indicate export or recompression |
| tags | Software, handler, and timing clues | Often exposes editing, conversion, or stripping |
| codec_name | Video or audio codec | Helps distinguish native capture from synthetic or edited output |
| width / height | Stream dimensions | Can show resizing, reframing, or platform processing |
| sample_rate | Audio stream properties | Useful when the audio path looks separate from the video path |
I pay close attention to consistency across these fields. A file can look ordinary in one field and still fail the broader pattern test. For example, a clean MP4 container with AAC audio is not reassuring by itself if the handler names, timing tags, and frame structure point to a desktop export pipeline.
Use FFprobe as a comparison tool
FFprobe is strongest when used across multiple versions of the same footage.
Run it against:
- The received file
- A known genuine file from the same device class, if you can get one
- Any reposted, downloaded, or platform-derived copy of the clip
That comparison separates routine platform processing from source-level anomalies. A social platform may remove tags, change bit rate, or transcode the file completely. A source file that already shows evidence of re-encoding before upload raises a different question.
Teams building a repeatable review process usually pair FFprobe with broader forensic video analysis software so the metadata findings sit alongside frame analysis, artifact review, and case documentation.
Bring in ExifTool for broader extraction
FFprobe tells you how the file is built. ExifTool helps identify what else is attached to it.
Use:
exiftool input.mp4
ExifTool often exposes software identifiers, embedded dates, manufacturer-specific fields, and private tags that simpler viewers skip. That matters in tampering cases because editors, mobile apps, AI generation workflows, and metadata scrubbers do not all clean up after themselves in the same way. One tool may remove visible fields but leave private tags or conflicting timestamps behind.
In practice, FFprobe and ExifTool answer different questions. FFprobe is better for structural coherence. ExifTool is better for hidden residue.
What command-line output often reveals in tampered files
The useful clues are rarely dramatic. They are small inconsistencies that line up.
Look for:
- Stream mismatches. Audio and video appear to come from different workflows or export histories.
- Software residue. Tags reference editing, conversion, or mobile utility apps that the source did not disclose.
- Timestamp conflicts. Embedded dates and file-system dates do not support the claimed chain of events.
- Container-stream disagreement. The wrapper looks typical, but the internal streams show a different production path.
- Metadata stripping with selective leftovers. Many fields are blank, but a few private or handler tags still reveal prior processing.
That last pattern shows up often in suspect AI-generated or deepfake material. The operator strips obvious metadata to make the file look neutral. The file then presents as oddly sparse, yet still carries technical remnants of export, assembly, or postprocessing. Sparse metadata is not proof of fabrication, but in a contested case it is a reason to examine the file more aggressively.
One caution matters. Missing metadata does not establish authenticity or fabrication on its own. Some genuine files are sparse because of the recording app, transfer method, or platform pipeline. The question is whether the remaining technical evidence makes sense as a whole.
This walkthrough is worth seeing in action:
Build a defensible record
Save the raw command output with the original file hash, acquisition notes, and chain-of-custody record. In legal and investigative work, reproducibility matters as much as the finding itself. If opposing counsel, an editor, or a platform trust team asks why the file was flagged, the answer should be a preserved record of what the tools returned and when you captured it.
Field note: Keep the command output with the case file. It is part of the evidence trail.
Key Metadata Fields That Signal Authenticity
Pulling metadata is easy. Reading it well is harder. The useful question isn't “what fields exist?” It's “which fields help test the claim attached to this file?”
Timestamps that agree, or don't
Start with time. Look at creation, modification, encoding, and any upload-related timing if the file came from a platform.
A credible file usually has a chronology that makes sense. Capture should precede export. Export should precede upload. Modification shouldn't predate creation. If the sequence is impossible or oddly compressed, something happened to the file that the sender hasn't explained.
Here's a simple interpretation table:
| Timestamp pattern | Likely meaning | Investigative response |
|---|---|---|
| Creation and modification are close and plausible | Normal capture or quick transfer | Continue with device and encoding checks |
| Encoding date appears after claimed “original” capture | Export or recompression occurred | Ask what software touched the file |
| Dates conflict with event timeline | Story may be wrong or file may be recycled | Compare against external chronology |
| Only partial timing survives | File may have been platform-processed or stripped | Don't overstate conclusions |
Device and source details
If the sender says the clip came straight from a smartphone or camera, the source fields should at least be plausible for that claim. Depending on the file and workflow, you may see manufacturer, model, camera settings, creator tags, or private vendor data.
What matters here is fit. A supposedly direct handset clip with no trace of the device and clear signs of export software deserves questions. A professional camera file may legitimately contain richer technical detail than a phone share sent through messaging apps.
Software fingerprints
Software tags can be revealing because people often forget they exist. They may show that a file passed through an editor, converter, or transcoding workflow before it reached you.
That doesn't mean the video is fake. It means it's not original in the simple sense many sources imply. For legal review, that distinction matters. For journalism, it changes how you describe provenance and whether you can present the clip as firsthand evidence.
Metadata rarely says “fraud.” More often it says “this file had a life before it got to you.”
Container and stream coherence
A file isn't just one object. It's a container holding one or more streams. Authenticity analysis gets stronger when you compare them against each other.
Look for coherence between:
- Container type and claimed source
- Video codec and likely capture device
- Audio stream properties and expected recording path
- Resolution and probable export history
For example, a file can have a polished container presentation while the stream internals suggest multiple processing stages. That doesn't happen by magic. Someone or something built that file.
Geographic clues
GPS is powerful when present and dangerous when absent from your reasoning. If coordinates exist, compare them to the claimed capture location. If they don't, resist jumping to conclusions. Many workflows strip location data during transfer or upload.
When GPS is present, it's one of the quickest ways to challenge a false narrative. A video presented as local footage but tagged to another region has to be explained before anyone should rely on it.
Interpreting Red Flags and Spotting Tampering
The most important shift in video verification is this: investigators can't assume metadata is merely incomplete. Sometimes it has been actively manipulated to defeat review.
According to the verified data summarized in Canto's video metadata article, over 68% of AI-generated videos distributed on social media had deliberately stripped or falsified metadata, and this tactic increased by 42% in the last 12 months. That is the context professionals need to work in. Missing or misleading metadata is now part of the deception strategy, not just a byproduct of sharing.
Red flag patterns that matter
A single anomaly rarely proves much. Patterns do.
Suspicious absence
The file lacks expected source clues, yet presents itself as untouched original footage. Missing data can be innocent, but in a synthetic or deceptive workflow it can also be the point.Chronology that fails basic logic
Capture, modification, and encoding events don't line up. When a source can't account for that sequence, the file's provenance weakens.Software traces inconsistent with the claim
A clip described as a direct witness recording shouldn't bear traces of an export pipeline unless the sender disclosed it.Location contradiction
The metadata points somewhere incompatible with the stated event or origin.
What deliberate stripping looks like in practice
Tampering often looks cleaner than authentic capture. That's counterintuitive, but it's common. The file arrives with just enough information to play normally and almost nothing else to examine. No useful device details. No location. Minimal timing. No obvious editor tag. It feels sterile.
That's where inexperienced reviewers make the mistake of calling the file “clean.” In practice, sterile metadata can be more suspicious than messy metadata, especially when the surrounding claim is dramatic and the sender offers no chain of custody.
Build a conclusion from multiple clues
Use a synthesis model rather than a yes-or-no checklist:
| Combined clues | Likely interpretation |
|---|---|
| Sparse metadata + strong source claim + no chain of custody | Treat as unverified and potentially stripped |
| Normal timing + plausible device data + coherent streams | More consistent with authentic origin, still not conclusive |
| Platform copy + weak metadata + visible re-encoding signs | May reflect upload processing rather than deception |
| Conflicting time, place, and software history | High-priority escalation for deeper forensic review |
Don't ask whether one field looks wrong. Ask whether the file behaves like the story told about it.
One caution investigators need to keep
Not every manipulated-looking file is synthetic, and not every synthetic file carries obvious metadata anomalies. A mundane action like forwarding through an app can strip useful fields. An advanced operator can spoof others. The job is to identify contradictions, document them, and combine metadata findings with frame, audio, and temporal analysis before reaching a final conclusion.
Verification Best Practices and Its Inherent Limitations
The right way to check video metadata is to treat it as one layer in a larger verification process. It's often the fastest layer, and sometimes the most revealing, but it's not the whole case.
Start with preservation. Keep the original file untouched, work from a copy, and document every extraction step. If the file may become evidence, basic evidence preservation practices matter as much as the technical review itself.
Then use a disciplined sequence:
- Triage the file quickly with OS-level inspection or a controlled viewer.
- Extract deep metadata with FFprobe and, where needed, ExifTool.
- Compare the metadata to the claim about source, time, place, and workflow.
- Escalate to non-metadata checks when the stakes justify it.
Those non-metadata checks matter because metadata can lie, disappear, or survive only in fragments. A thorough review also needs frame-level artifact analysis, audio forensics for spectral anomalies, and temporal consistency checks across the clip.
The practical limitation is simple. Clean metadata does not guarantee authenticity, and suspicious metadata does not automatically prove fabrication. It gives you indicators. You still need corroboration.
That's why the most reliable workflows are multi-signal and privacy-conscious. For teams that need a faster operational path, AI Video Detector provides a privacy-first way to assess video authenticity using metadata inspection alongside frame, audio, and temporal analysis, without storing user videos. If you need to make a decision before publication, escalation, or evidentiary use, that kind of layered review is the safer standard.
Need a faster second opinion on a suspicious clip? AI Video Detector analyzes uploaded videos using metadata inspection, frame-level analysis, audio forensics, and temporal consistency checks to help teams separate authentic footage from manipulated or AI-generated content.
