General

File Integrity and Checksums: Verifying Your Conversions

Published Mar 19, 2026 5 min read By ChangeThisFile Team

Quick Answer

Checksums are fingerprints for files: fixed-length values computed from file contents that change if even a single bit is altered. SHA-256 is the standard for verifying file integrity after conversions, downloads, and transfers. If the checksum matches, the file is identical; if it doesn't, something changed.

You converted a 2GB video file and the output looks fine — but is it actually complete? You downloaded a software installer and it runs — but is it the genuine, unmodified file? You transferred 10,000 photos to a new drive and the count matches — but are all the files intact?

Checksums answer these questions definitively. A checksum is a fixed-length value computed from the contents of a file using a hash function. Change one bit in a 10GB file and the checksum changes completely. Checksums don't tell you what changed, but they tell you conclusively whether anything changed. This guide covers the major checksum algorithms, when to use each, and how to verify file integrity in practice.

How Checksums Work

A checksum algorithm reads every byte of a file and produces a fixed-size output (the "digest" or "hash"). The same input always produces the same output. Different inputs produce different outputs (with extremely high probability). The output is typically represented as a hexadecimal string.

Example: the SHA-256 hash of the string "hello" is 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Change "hello" to "Hello" and the hash becomes 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969 — completely different. This avalanche effect is by design: even a 1-bit change in the input flips roughly half the bits in the output.

File checksums are computed the same way, just on larger inputs. A SHA-256 hash of a 10GB video file is still a 64-character hex string. Computing it takes a few seconds (SHA-256 processes data at 200-500 MB/s on modern CPUs).

Checksum Algorithms Compared

Algorithm	Output Size	Speed	Collision Resistance	Use Case
CRC32	32 bits (8 hex chars)	Very fast	Low (collisions expected for large datasets)	Error detection in archives (ZIP, PNG, Ethernet)
MD5	128 bits (32 hex chars)	Fast	Broken (collisions can be crafted in seconds)	Legacy checksums, non-security file verification
SHA-1	160 bits (40 hex chars)	Fast	Broken (Google/CWI produced collision in 2017)	Git (still), legacy systems
SHA-256	256 bits (64 hex chars)	Moderate	Strong (no known practical attacks)	Standard for integrity verification, software distribution
SHA-512	512 bits (128 hex chars)	Faster than SHA-256 on 64-bit CPUs	Strong	High-security applications, slightly faster on modern hardware
BLAKE3	256 bits (default)	Very fast (parallelizable)	Strong	Modern alternative, 5-10x faster than SHA-256

Which Algorithm to Use

For file integrity verification (conversions, transfers, backups): SHA-256. It's the standard, universally supported, and secure. No practical attacks exist or are foreseeable.

For speed-critical bulk operations: BLAKE3 if your tools support it (5-10x faster than SHA-256). Otherwise, MD5 is adequate for non-security integrity checks — its collision weakness only matters when an adversary is trying to create a fake file with the same hash, not for detecting accidental corruption.

For archive integrity: CRC32 is already built into ZIP, RAR, 7Z, and PNG. You don't choose it — it's automatic. It catches transmission errors and bit flips but isn't suitable for detecting deliberate tampering.

Never use for new projects: MD5 and SHA-1 for security purposes. Both have demonstrated collision attacks. MD5 collisions can be generated in seconds on a laptop.

Verifying File Integrity After Conversion

Checksums are most useful for lossless operations where the output should be deterministic:

Archive conversion: ZIP to 7Z should extract to identical files. Compute checksums on the contents of both archives — every file should match.
Container remux: MKV to MP4 with stream copy should produce bitwise-identical audio/video streams. Extract streams with FFmpeg and compare checksums.
Lossless format change: WAV to FLAC and back to WAV should produce a file identical to the original. Compute SHA-256 on both WAVs — they must match.
Text format conversion: JSON to YAML and back to JSON should round-trip. Compare normalized outputs (ignoring whitespace differences).

For lossy conversions (PNG to JPG, WAV to MP3), checksums can't verify "quality" — the output is intentionally different from the input. Instead, verify that the output file isn't corrupted by checking that it opens correctly and has a reasonable file size.

Verifying Downloads

Software distributors publish checksums alongside download links. The process: download the file, compute the checksum locally, compare with the published value. If they match, the file is genuine and uncorrupted.

On macOS/Linux:

shasum -a 256 downloaded_file.iso

On Windows (PowerShell):

Get-FileHash downloaded_file.iso -Algorithm SHA256

On Windows (cmd):

certutil -hashfile downloaded_file.iso SHA256

Compare the output string with the published hash. They must match exactly — a single character difference means the file is different.

Checksum Files: .md5, .sha256, .sfv

Checksum files store hash values alongside filenames for bulk verification:

.md5 file format:

d41d8cd98f00b204e9800998ecf8427e  file1.mp4
7d793037a0760186574b0282f2f435e7  file2.mp4

.sha256 file format: Same layout, longer hashes.

.sfv (Simple File Verification): Uses CRC32, commonly used for Usenet downloads and game ROM sets.

file1.mp4 3A4B5C6D
file2.mp4 1E2F3A4B

Generate checksum files:

# Generate SHA-256 checksums for all files in a directory
sha256sum * > checksums.sha256

# Verify all files against the checksum file
sha256sum -c checksums.sha256

The -c (check) flag reads the checksum file and verifies each listed file, printing OK or FAILED for each. This is the standard way to verify a batch transfer or backup.

Practical Checksum Use Cases

Backup verification: After copying files to a new drive, generate checksums on the source, copy the checksum file, and verify on the destination. This catches bit-rot, copy errors, and filesystem issues that a simple file count misses.
Batch conversion validation: After converting 1,000 FLAC files to MP3 and later converting the MP3 back to WAV to spot-check, use checksums to verify the round-trip. (Note: lossy round-trips won't match the original; this only works for lossless conversions.)
Deduplication: Two files with the same SHA-256 hash are identical with virtual certainty. Hash all files in a directory tree and group by hash to find duplicates — regardless of filename.
Transfer verification: When sending large files over unreliable connections, compute the checksum before sending and after receiving. If they match, the transfer was error-free.
Archive integrity monitoring: Generate checksums for your file archive once. Periodically re-verify to detect bit-rot (silent data corruption on aging storage media). Any mismatch means a file has been corrupted since the last check.

Checksums are the simplest and most reliable tool for answering "is this file the same as that file?" A 64-character string tells you more about a file's integrity than any amount of visual inspection. Use them after batch conversions, after large transfers, and as part of any backup strategy. The 5 seconds it takes to compute a SHA-256 hash can save hours of debugging a corrupted file.

Key Takeaways

SHA-256 is the standard checksum algorithm for file integrity verification — fast, secure, universally supported
MD5 is broken for security but still adequate for non-adversarial integrity checks (detecting corruption, not tampering)
Lossless conversions (WAV to FLAC, ZIP to 7Z) can be verified by checksumming the round-trip output
Always verify large transfers with checksums — file counts alone don't catch corruption
Use 'sha256sum -c checksums.sha256' to bulk-verify files against a checksum manifest
CRC32 is built into ZIP, PNG, and network protocols — you're already using checksums without knowing it

Frequently Asked Questions

Can two different files have the same checksum?

Theoretically yes — this is called a collision. For SHA-256, the probability is 1 in 2^256, which is a number so large it exceeds the number of atoms in the observable universe. No SHA-256 collision has ever been found, and none is expected within the lifetime of the universe using current technology. For MD5, collisions can be deliberately crafted in seconds, which is why MD5 is broken for security — but accidental MD5 collisions are still astronomically unlikely.

Is MD5 still safe to use for checking file integrity?

For non-security purposes (detecting accidental corruption or verifying a file transfer), MD5 is fine. Its collision vulnerability only matters when an attacker is trying to create a malicious file with the same hash as a legitimate one. For checking whether your backup copy matches the original, or whether a conversion produced a complete file, MD5 is fast and adequate. For security-sensitive verification (software downloads, code signing), use SHA-256.

How long does it take to compute a checksum for a large file?

SHA-256 processes data at 200-500 MB/s on modern CPUs (faster with hardware acceleration). A 1GB file takes 2-5 seconds. A 10GB file takes 20-50 seconds. BLAKE3 is 5-10x faster (1-3 GB/s), making it practical for very large files and bulk operations. The bottleneck is usually disk read speed, not the hash computation itself.

Can checksums tell me what changed in a file?

No. A checksum tells you whether anything changed, not what or where. If two checksums don't match, you know the files are different, but you need other tools (binary diff, hex editor) to find the specific differences. Think of checksums as a pass/fail test — they detect a problem but don't diagnose it.

Should I verify checksums after every file conversion?

For routine single-file conversions, it's usually overkill — if the output opens and looks correct, it's fine. For batch conversions (hundreds or thousands of files), checksum verification catches silent errors that visual inspection misses. For lossless operations (archive conversion, container remux, lossless audio conversion), checksums are the only way to prove the output is identical to the input.

What is bit-rot and how do checksums help?

Bit-rot is silent data corruption where bits flip on storage media over time due to magnetic decay, cosmic rays, or firmware bugs. A file may appear normal (correct name, correct size) but have corrupted data inside. Checksums detect this: compute hashes when files are known-good, then periodically re-verify. Any mismatch means corruption has occurred. ZFS and Btrfs filesystems do this automatically with built-in checksumming.

How do I compare two directories to check if all files are identical?

Generate checksum files for both directories and compare them. On Linux/macOS: 'cd dir1 && sha256sum * > /tmp/dir1.sha256' then 'cd dir2 && sha256sum -c /tmp/dir1.sha256'. Every file will report OK or FAILED. For recursive comparison including subdirectories, use 'find dir1 -type f -exec sha256sum {} \;' and compare the sorted output.

Why do some downloads provide both MD5 and SHA-256 hashes?

For backward compatibility. MD5 was the standard for decades, and many older scripts and tools expect MD5 hashes. SHA-256 is the modern standard. If both are provided, use SHA-256 — it's more secure and just as fast on modern systems. The MD5 hash is there for users with older tools that don't support SHA-256.

Ready to convert your files?

Use ChangeThisFile to convert between 600+ formats — free, fast, and private.

Start Converting