How to find duplicate video files

A matching name is not a duplicate

Production teams and in-house content teams collect copies. A camera original, a copy on another drive, a file dropped into a second folder, an export someone renamed so a cut would relink. The name often changes on the way. Two files can share a name and still differ. Two files can carry different names and be the same bytes. A filename is a label. It is not proof that the files match, and it is not proof that they differ. The same is true of movie files. The extension is another label. A .mov and a .mp4 are still files, and the test is still the bytes.

File size is the next check people reach for. If the sizes differ, the files cannot be identical. If the sizes match, you still do not know. Plenty of clips land on the same byte count and hold different pictures. Size eliminates candidates. It does not confirm a duplicate.

In a real library the same clip often sits in more than one place. The camera card copy, the folder the edit linked, a delivery folder, a second volume someone mirrored by dragging files across. Each stop can rename the file. A spreadsheet of names will not tell those copies apart from a new export that happens to reuse a name. You have to read the file.

An exact duplicate is the same bytes

An exact duplicate is byte for byte the same file. A full checksum, such as SHA-256, is a fingerprint of every byte. When two files produce the same SHA-256, they are identical. That is why a renamed export can be identical to a camera original: the bytes were copied, and the name was what changed. The name on the export does not decide the question. The checksum does.

A re-encoded export is a different case. It can look like the original, run for about the same duration, and still be a new file with new bytes. That file is not an exact duplicate. Deleting the camera original because the export looks right is how a team loses the master. Keep the camera original. Delete an extra copy only after a full checksum confirms the bytes match, and only after you know which path the edit still uses.

The practical order is the cheap test first. Different sizes are finished. Files that share a size can be sampled with a partial hash, which throws out pairs whose sampled bytes differ. Anything still standing needs a full checksum before you call it a duplicate. A partial hash is a filter. It is not the proof.

A partial hash reads only a piece of the file. That is enough to reject two files whose sampled bytes differ, and it saves a full read of a large clip that was never a candidate. It is the middle step, not the last one. Two files can match on the bytes that were sampled and still differ later in the file. Only the full checksum closes that gap.

What each method can and cannot prove

On a Mac

Drive Inspector is a free Mac app for macOS 13 or later. Point it at a drive, a RAID, or a mounted share. It reads that volume and never writes to the volume it scanned. It matches duplicates on contents, not on filenames. Files are grouped by exact byte size, survivors are partial-hashed, and anything still matching is confirmed with a full SHA-256 hash. It reads codec, resolution, frame rate, and duration from the file headers, and it never decodes a frame. It can reveal a file in Finder, and it exports an HTML or CSV report. It never deletes anything itself. Only verified extra copies of files over 4 MB count toward its reclaimable number.

In a browser, or on a PC or Linux

Browser Duplicate Finder does the comparison without a download. Pick a folder in the browser. The browser reads and hashes the files you picked, on your machine, and nothing is uploaded. Filenames do not decide a match. You get a duplicate report. It never deletes or changes a file.

On a PC or on Linux, checksum tools exist. Compute a SHA-256 of the files you suspect and compare the hashes. The same hash means the bytes are the same. The same name, or the same size, does not. You still choose which copy to keep. The camera original is the one to keep unless you already know a later file is the master the edit uses.

A similar clip is not an identical file

Visual similarity asks whether two clips look alike. That can matter when you are hunting a recut, a resized picture, or a shot that was graded. It does not prove the files are the same, and it will not, by itself, tell you that a renamed copy is byte for byte the camera original. For a production library the first question is usually the exact one: are these the same bytes. Similarity is a later question, and it needs a person to look, or a separate comparison of the pictures. It is not a substitute for the checksum.

Finding a copy is not the same as finding a clip

A checksum tells you that two paths hold the same file. It does not tell a producer which interview answered the question, or which take the edit used. Media Nexus is the media archive Vaultline Solutions builds. It indexes a team's existing media storage in place. Approved volumes are read. Originals stay where they are. It does not rename, move, or delete them. Search can use file names, tags, and transcripts. Media Nexus is not a backup, and indexing a volume does not delete the extra copy.

Searching footage on a NAS is how the team finds a clip in the files that are already on the storage. Archiving the footage so the team can still find it is where those files should sit, and how a further copy gets checked. A duplicate check does not replace that index. The index does not decide which extra copy you can remove.

Before you delete anything

• Different file sizes are not duplicates. Stop there.
• Confirm what remains with a full checksum, such as SHA-256.
• Treat a matching filename as a hint, not a result.
• Keep the camera original.
• Remove an extra copy only after the checksum matches, and only if the edit does not still use that path.

How a team starts

This is for in-house content teams and small production teams whose footage already lives on a NAS, a RAID, or drives they control. The Free Build builds that archive against your real media before you decide whether to keep it. Build before you buy is the intake that configures the archive before any payment.