How to tell if a file is corrupted on a Mac
Without the original, you can only check that a file decodes cleanly. Test archives with unzip -t or gzip -t, decode videos with ffmpeg -v error -i file -f null -, and convert images with sips. These catch most damage, but not all of it. The only proof a file is intact is a matching hash, such as shasum -a 256, against a known-good copy or a saved checksum list.
What does a corrupted file look like?
Corruption means some of the bytes in a file are wrong or missing. What you see depends on where the damage falls and how the format handles it:
- Photos: a grey or single-colour band across the lower part of the image, colours shifted from one point down, a half-drawn image, or a file that won't open at all. A RAW file can show its embedded preview and still fail when Preview or your editor renders the full image, because the preview is stored separately from the RAW data.
- Video: green or grey blocks, smeared frames, audio dropouts, a clip that freezes at the same point every time, a duration that's wrong or shows as zero, or a file that won't play at all. A clip cut off before the end often won't open, because many MP4 and MOV files store their index at the end.
- Archives: Archive Utility reports an error when you open a
.zipor.tar.gz, or Terminal tools report a CRC error. - Documents: a PDF with blank or missing pages, or Pages, Word or Excel saying the file can't be opened or needs repair.
The catch is that a corrupted file often looks fine. A flipped bit in the middle of a long video can show up as a single glitched frame you'd never notice while scrolling. That's why the checks below matter.
file command, Get Info, and file size. They only read the file's header or its length. In testing, a JPEG cut off at 70% of its size was still reported by file as a JPEG with the correct dimensions.How can I check a file without the original?
If you don't have the original, the best you can do is ask a program to read the whole file and complain about anything that doesn't make sense. The commands below were tested on macOS 26 in Terminal (zsh). Files with spaces in the name need quotes around the path.
Zip archives: unzip -t
unzip -t ~/Downloads/project.zipBuilt in. It decompresses each file in memory and compares it with the CRC checksum stored in the zip. A good archive ends with No errors detected; a damaged one names the file with bad CRC. Because zips carry their own checksums, this test is strong.
Gzip and tar.gz files: gzip -t
gzip -t backup.tar.gz && echo OKBuilt in. Gzip files also store a CRC, so gzip -t catches damaged data. For .bz2 and .xz files, bzip2 -t and xz -t do the same (bzip2 is built in; xz comes from Homebrew).
Tar archives: tar -tf (structure only)
tar -tf backup.tarThis lists the contents and catches a truncated or badly damaged archive. It is weaker than it looks. In testing, macOS's tar listed and even extracted a .tar.gz with damaged data without reporting an error, while gzip -t caught it. A plain, uncompressed .tar has no checksum over file contents at all, so damage inside a file can't be detected without the original.
Video and audio: ffmpeg
ffmpeg -v error -i clip.mov -f null -ffmpeg isn't included with macOS. Install it with Homebrew (brew install ffmpeg). This command decodes every frame and every audio sample and sends the result to ffmpeg's null muxer, which writes nothing. With -v error, a clean file prints nothing. Any output, such as Invalid NAL unit size or moov atom not found, means damage.
Read the output, not the exit status. In testing, ffmpeg reported decode errors in a damaged MP4 and still exited with status 0. It only exits with an error when it can't open the file at all. The check takes about as long as decoding the clip, so long 4K footage takes a while.
Photos: sips, Preview and Quick Look
sips -s format png photo.jpg --out /tmp/check.pngsips is built in and uses macOS's own image decoding. Converting forces a full decode: a file that can't be decoded fails with Error 13. It's a coarse test. In testing, a JPEG with a few kilobytes of garbage in the middle converted without complaint, while ffmpeg flagged it (ffmpeg -v error -i photo.jpg -f null - works on JPEGs too). For RAW files, sips works when your macOS version supports that camera's RAW format.
The visual check still matters. Select files in Finder and press the Space bar to open Quick Look, then use the arrow keys to step through them, looking for grey bands or colour shifts. From Terminal, qlmanage -p photo.jpg opens the same preview.
ExifTool (third-party, brew install exiftool) can run exiftool -validate -warning -a photo.jpg, but that validates metadata, mainly EXIF and TIFF structures, not the pixels. Treat it as a supplement.
PDFs: pdfinfo
pdfinfo report.pdfpdfinfo comes with Poppler (brew install poppler), not macOS. It reports Syntax Error lines and exits with an error when a PDF is truncated or its structure is broken. It doesn't render pages, so damage inside a page can slip through. Opening the PDF in Preview and scrolling through every page is still worth doing.
Which check should I use for each file type?
| File type | Quick check | Command or tool | Built in? |
|---|---|---|---|
| JPEG, HEIC, PNG | Decode the whole image, then look at it | sips -s format png f --out /tmp/c.png, Quick Look | Yes |
| Camera RAW | Render the full image, not the thumbnail | Preview, Photos or your editor; sips | Yes |
| Video, audio | Decode every frame | ffmpeg -v error -i f -f null - | No (Homebrew) |
| .zip | Test stored CRCs | unzip -t f.zip | Yes |
| .gz, .tar.gz | Test stored CRC | gzip -t f.gz | Yes |
| .tar | Check structure only | tar -tf f.tar | Yes |
| Check structure, then scroll pages | pdfinfo f.pdf, Preview | No (Homebrew) | |
| Any file, with original or list | Compare hashes | shasum -a 256, cmp, shasum -c | Yes |
How do I check a file against the original?
If you still have the original, or a checksum list made when the files were known to be good, you can stop guessing. A SHA-256 hash changes completely if even one bit differs, so a match means the files are identical.
Compare one file with its original:
shasum -a 256 ~/Pictures/IMG_0412.CR3 /Volumes/Backup/IMG_0412.CR3The two 64-character hashes should be identical. For a quick yes/no, cmp prints nothing when files match, or the first position where they differ:
cmp original.mov /Volumes/Backup/original.movIf you saved a checksum list when you made the backup, check the whole folder against it:
cd /Volumes/Backup/Photos
shasum -a 256 -c ~/photos.sha256Each file is reported as OK or FAILED. Add --quiet to show only failures. The guide to verifying a file copy shows how to build that list.
Why can't format checks catch every corruption?
Format checks only know what a valid file looks like, not what your file should contain. Media formats are designed to keep playing through small errors, so a damaged pixel block or a few wrong audio samples can decode without any error. JPEG photos and H.264 video carry no checksum over the image data, and a plain tar has none over file contents.
Zip and gzip are stronger because they store a CRC of the original data, but that only proves the archive matches itself. It can't tell you whether the files went in damaged.
So the honest summary: a clean format check means "probably fine". A matching hash against a known-good copy means "identical". If the original is gone and no checksum was ever recorded, there is no way to prove a file is intact.
How do I find and fix damaged files in a backup?
If you have a known-good source, such as the original card, drive or folder, VerifiedCopy's Verify & Repair scans the backup against it chunk by chunk, comparing SHA-256 hashes. It rewrites only the chunks that don't match and re-verifies them, rather than re-copying whole files. The Integrity view shows a block map of each file's intact, corrupted and repaired chunks, so you can see exactly where the damage was. A scan can also save a hash manifest for later checks.
For new copies, VerifiedCopy's Copy & Verify reads each chunk back after writing it and compares its SHA-256 with the source, so damage is caught while the original is still in hand.
Frequently asked questions
Can a file be corrupted if it still opens?
Yes. A photo can open with a grey band at the bottom, and a video can play normally until it reaches the damaged section. Opening a file only proves its header is readable, not that every byte is correct.
Does the file command detect corruption?
No. file only reads the first bytes to identify the format. A JPEG cut off halfway is still reported as JPEG image data with the right dimensions. Use a check that decodes the whole file instead.
Is there a built-in way to check a video for corruption on Mac?
macOS doesn't include a command-line video checker. You can play the clip through in QuickTime Player and watch for glitches, or install ffmpeg with Homebrew and run ffmpeg -v error -i clip.mov -f null - to decode every frame and print any errors.
Can I fix a corrupted file?
The reliable fix is to copy the file again from a good copy. Repair tools for specific formats can sometimes rescue part of a damaged video or archive, but they can't restore data that was never written correctly. If you still have the original, replace the damaged copy and verify it with a checksum.
Does a clean ffmpeg check mean my video is perfect?
Not quite. It means every frame decoded without an error, which rules out most damage. A few wrong bytes inside a frame can still decode as a slightly wrong picture with no error. Only a matching SHA-256 hash against a known-good copy proves the file is identical.