Compute the checksum of a file

A checksum (sometimes spelled chksum) is a unique digital fingerprint computed from a file's content by a hash algorithm. This fingerprint is generally represented as a fixed-length hexadecimal string.

The fundamental property of a good hash algorithm is the avalanche effect: any change to the source file, even of a single bit, produces a radically different checksum. Two files with strictly identical content always produce the same checksum, regardless of the filename, modification date or operating system.

The checksum is mainly used to verify a file's integrity: if the fingerprint recomputed locally matches the one announced by the publisher, the file is intact. Otherwise, it has been altered, corrupted in transit, or modified.

• Verifying a download's integrity: a Linux ISO (Debian, Ubuntu, Fedora, Arch), a Docker image, a Windows installer or an open source archive always publish an official checksum. Recomputing it locally confirms that the file is complete and unaltered.
• Detecting in-transit corruption: a cut download, a failing disk sector, unstable RAM, a flaky network cable, or a copy to a USB stick can corrupt bytes. The checksum immediately reveals these silent errors.
• Signature fingerprint: confirm that a file really comes from the expected author when the checksum is distributed via a secure channel (HTTPS, GPG signature). This is the mechanism behind Linux package repositories and app stores.
• Versioning and caching: Git identifies each commit, blob and tree by a SHA-1 hash (migrating to SHA-256). CDNs and web bundlers (Webpack, Vite, esbuild) inject a hash into the filename (app.4a8f2c.js) to automatically invalidate the browser cache on a change.
• Duplicate detection and deduplication: incremental backups (Borg, Restic, rsync), filesystems (ZFS), and object stores identify identical blocks by their hash to store only one copy.
• Upload validation: a client sends the expected checksum, the server recomputes it on receipt. AWS S3, for example, accepts a Content-MD5 or x-amz-checksum-sha256 header to reject a corrupted upload.
• Threat intelligence and antivirus: VirusTotal and antivirus vendors index malicious files by their SHA-256 hash, allowing detection without transmitting the full binary.

• MD5 (128 bits, 32 hexadecimal characters): fast, widely distributed, but cryptographically broken. MD5 collisions have been computable in seconds on common hardware since 2004. To be used only for non-malicious integrity verification (download against a network glitch, local backup). Forbidden for any security, signature, or authentication function.
• SHA-1 (160 bits, 40 hexadecimal characters): deprecated for cryptography since the 2017 SHAttered attack, which demonstrated a real collision between two distinct PDFs. Git still uses it by default but is migrating to SHA-256. No longer to be used to sign or authenticate.
• SHA-256 (256 bits, 64 hexadecimal characters): modern standard, member of the SHA-2 family. Basis of modern TLS certificates, Linux package signatures (apt, dnf, pacman), Bitcoin, and official integrity checks. Slower than MD5 but safe as far as current knowledge goes.
• SHA-512 (512 bits, 128 hexadecimal characters): 64-bit variant of SHA-2. Handles 64-bit words natively, which makes it sometimes faster than SHA-256 on a 64-bit CPU. Longer fingerprint, higher security margin.
• CRC32 (32 bits, 8 hexadecimal characters): non-cryptographic, ultra-fast, specifically designed to detect transmission errors. Used by Ethernet, ZIP, PNG, gzip. Does not protect against malice: an attacker can trivially forge a file with the same CRC32 as another. Suited to fast hardware checks, not security.

• Verifying a Linux ISO: Debian, Ubuntu, Fedora and Arch publish the SHA-256 and SHA-512 of each official image, often co-signed in GPG.
• Validating a signed binary: confirm that an executable downloaded from a mirror has not been replaced by a tampered version.
• Comparing two versions: before and after a change, an identical checksum proves bit-for-bit identity, without having to share the files.
• Upload validation: the client sends a checksum, the server recomputes it on receipt to confirm the absence of corruption.
• Fingerprinting: detection of bots or known files in fingerprint databases (antivirus, threat intelligence, duplicate search).

1. Drag and drop the file into the dedicated area, or use the selection button.
2. Pick the algorithm: MD5, SHA-1, SHA-256, SHA-512 or CRC32.
3. The checksum displays, ready to copy.
4. Compare the value obtained with the reference one (published by the publisher or kept locally).

Computation happens locally in your browser, without sending the file to a remote server. The content stays confidential.

The standard verification procedure is as follows:

1. The official site publishes the expected checksum, for example d41d8cd98f00b204e9800998ecf8427e for MD5 or a 64-character string for SHA-256.
2. Download the file.
3. Compute its checksum, either with this tool, or from the command line.
4. Compare: if both strings are strictly identical, character by character, the file is intact. If they differ, even by a single character, the file is corrupted or tampered with: do not use it, download it again.

From the command line on Linux:

# Compute the checksum
md5sum file.iso
sha1sum file.iso
sha256sum file.iso
sha512sum file.iso
cksum file.iso             # CRC32 + size

# Automatically verify from a .sha256 file published by the publisher
sha256sum -c file.iso.sha256
# Displays: "file.iso: OK" if the checksum matches

On macOS:

md5 file.iso
shasum -a 1 file.iso
shasum -a 256 file.iso
shasum -a 512 file.iso

# Verification from a reference file
shasum -a 256 -c file.iso.sha256

On Windows (PowerShell):

Get-FileHash file.iso -Algorithm MD5
Get-FileHash file.iso -Algorithm SHA1
Get-FileHash file.iso -Algorithm SHA256
Get-FileHash file.iso -Algorithm SHA512

# Compare with an expected value
(Get-FileHash file.iso -Algorithm SHA256).Hash -eq "ABC123..."

Algorithm	Size	Speed	Recommended use
CRC32	32 bits	Very fast	Network or storage error detection, non-cryptographic
MD5	128 bits	Fast	Non-hostile integrity only, avoid in security contexts
SHA-1	160 bits	Fast	Obsolete, legacy compatibility (Git, old packages)
SHA-256	256 bits	Moderate	Current standard, integrity verification and signatures
SHA-512	512 bits	Fast on 64-bit	Integrity verification, higher security margin

MD5 or SHA-256 to verify my ISO?

SHA-256 by default. Almost all modern Linux distributions publish SHA-256 and SHA-512, sometimes alongside MD5 for historical compatibility. If the publisher only publishes MD5 and you fear a compromise, require SHA-256 or verify the GPG signature of the checksums file. If you just fear a download corruption, MD5 is technically enough.

Does the checksum guarantee my file's security?

No, not on its own. A checksum proves integrity, not authenticity. If an attacker controls the download server, they can publish a modified file and its modified checksum. Real security comes from a digital signature (GPG, code signing) that ties the checksum to a known private key. Always fetch the checksum via HTTPS or, better, via a verifiable GPG signature.

My checksum does not match, what should I do?

First, check that you are comparing the right algorithm: a SHA-256 cannot match a SHA-1. Then download again, ideally from another mirror: the most frequent cause is a network glitch. If the mismatch persists after several attempts, suspect a mirror compromise: go back to the official source and check the GPG signature if it exists. Never run or use the file until the checksum matches.

Why is MD5 deprecated?

MD5 suffers from practical collisions: it is possible to build two different files with exactly the same MD5 hash in a few seconds. This property violates the very function of a cryptographic hash. Concretely, an attacker can create a malicious binary with the same MD5 as a legitimate one. SHA-1 suffers from the same problem since 2017 (SHAttered attack). Only SHA-256, SHA-512 and their variants remain considered safe in 2026.

Difference between hash and checksum?

A hash is the generic result of a hash function. A checksum is a hash specifically used to verify the integrity of data. All checksums are hashes, but not all hashes are checksums: a password hash (bcrypt, argon2) serves authentication, a hash in a hash table serves to index quickly. The term fingerprint is a common synonym of checksum.

Is CRC32 enough for my needs?

CRC32 is enough if you only seek to detect accidental corruption on a non-hostile channel: internal network transfer, ZIP archive verification, in-memory consistency check. With only 32 bits, two random files have about a 1 in 4 billion chance of having the same CRC32 by accident, which is enough for error detection. CRC32 is insufficient as soon as an attacker can influence the content: it is trivial to forge a file with a target CRC32. For any verification against a malicious risk, use SHA-256.

Why does my checksum differ depending on the OS?

The checksum of the same binary content is identical everywhere. If you get two different results, it means the file actually differs: line endings (Windows CRLF versus Unix LF) after an FTP transfer in text mode, text encoding modified at opening, metadata added by the system (macOS Spotlight resolution, extended attributes), or silent recompression by a transfer client. Always transfer in binary mode.

Checksum or digital signature?

A checksum proves that a file has not been altered between publication and receipt, provided the checksum is fetched via a secure channel. A digital signature (GPG, PGP, Authenticode code signing) additionally proves the author's identity thanks to a private key. The signature wraps and reinforces the checksum: the standard practice at Debian, Tor, or Bitcoin Core is to GPG-sign the checksums file, then to use these checksums to verify the binaries.