File Checksum Calculator

What is a File Checksum?

A file checksum is a fixed-size fingerprint computed from the entire contents of a file using a cryptographic hash function. It serves as a compact proof of integrity — if even a single byte in the file changes, the resulting checksum will be completely different. Checksums are fundamental to software distribution, backup verification, forensic analysis, and supply chain security, providing a mathematical guarantee that a file has not been corrupted or tampered with during transfer, storage, or deployment.

This tool computes file checksums entirely in the browser using the Web Crypto API (SubtleCrypto.digest()). No file data is uploaded to any server — the file is read locally via the File API, processed through hardware-accelerated cryptographic primitives, and the resulting hash is displayed immediately. This client-side approach guarantees privacy for sensitive files (binaries, firmware images, proprietary packages) while leveraging native browser performance that rivals command-line tools like sha256sum.

Algorithm Comparison: MD5, SHA-1, SHA-256, SHA-384, SHA-512

Choosing the right hash algorithm depends on your security requirements, performance constraints, and compatibility needs. Here is a comparison of the algorithms commonly used for file integrity verification:

• MD5 (128-bit): Produces a 32-character hex digest. Cryptographically broken — practical collision attacks exist since 2004 (Wang et al.). Still encountered in legacy systems, FTP mirrors, and older package managers. Do not use for security-critical integrity checks. Acceptable only for non-adversarial duplicate detection or checksum comparison against existing MD5 hashes published by trusted sources.
• SHA-1 (160-bit): Produces a 40-character hex digest. Deprecated since the SHAttered attack (2017) demonstrated practical collision generation. Git historically used SHA-1 for object addressing but is migrating to SHA-256. Avoid for new systems; use only when verifying against legacy SHA-1 checksums provided by upstream sources.
• SHA-256 (256-bit): The current industry standard for file integrity verification. Produces a 64-character hex digest. Used by Linux package managers (APT, DNF), Docker content addressing, npm package integrity (integrity field in package-lock.json), and most software distribution checksums published today. Provides 128-bit collision resistance — sufficient for all foreseeable applications.
• SHA-384 (384-bit): A truncated variant of SHA-512 producing a 96-character hex digest. Required by certain government and financial compliance frameworks (NIST Suite B). Shares SHA-512 internal structure, making it faster than SHA-256 on 64-bit processors while providing a larger security margin.
• SHA-512 (512-bit): Produces a 128-character hex digest with 256-bit collision resistance. The maximum security margin in the SHA-2 family. Preferred for long-term archival integrity and environments where future-proofing against cryptanalytic advances is a priority. Often faster than SHA-256 on modern 64-bit hardware because it operates on 64-bit words natively.

Recommendation: Use SHA-256 as the default for software verification workflows. Use SHA-512 when archival durability matters or when targeting 64-bit systems where it may outperform SHA-256. Only use MD5 or SHA-1 for backward compatibility with existing checksums.

Integrity Verification Workflows

File checksum verification appears in numerous real-world workflows where confirming that a file is unmodified is critical:

1. Software download verification: Linux distributions (Ubuntu, Fedora, Arch) publish SHA-256 checksums alongside ISO images. After downloading, you compute the checksum locally and compare it against the published value. A mismatch indicates corruption during transfer or potential tampering by a man-in-the-middle attacker.
2. Package manager integrity: npm stores SHA-512 hashes in package-lock.json under the integrity field (using Subresource Integrity format: sha512-<base64>). During npm install, each downloaded tarball is verified against this hash. Docker uses content-addressable storage where image layers are identified by their SHA-256 digest.
3. Backup verification: After creating a backup archive, compute its checksum and store the hash separately. Before restoring, recompute the checksum and verify it matches. This detects bit rot on storage media, silent data corruption from failing drives, or incomplete transfers to cloud storage.
4. Supply chain security: SLSA (Supply-chain Levels for Software Artifacts) and Sigstore frameworks use checksums as the foundation for provenance attestations. Build systems record the SHA-256 of every artifact produced, enabling consumers to verify that a binary was built from a specific source commit by a trusted builder.
5. Forensic analysis: Digital forensics practitioners compute checksums of evidence files immediately upon acquisition. The hash serves as a court-admissible proof that evidence was not altered during analysis. Chain-of-custody documentation includes hash values at each transfer point.

In all these workflows, the verification pattern is identical: compute, compare, decide. This tool handles the compute step — you provide the file, select the algorithm, and get the deterministic hash output for comparison against a known-good value.

Web Crypto API and Browser-Based File Hashing

The Web Crypto API (window.crypto.subtle) provides native, hardware-accelerated cryptographic operations in all modern browsers. For file hashing, the relevant method is SubtleCrypto.digest(algorithm, data), which accepts an ArrayBuffer and returns the hash as an ArrayBuffer. This is the same underlying implementation used by Node.js crypto module and command-line tools like openssl dgst.

For large files, reading the entire file into memory at once would be impractical. This tool uses the File API's FileReader or file.arrayBuffer() method to read file contents, then passes the buffer directly to crypto.subtle.digest(). For files exceeding available memory, a chunked approach using file.slice() combined with incremental hashing would be necessary — however, the Web Crypto API does not natively support streaming/incremental digests, so the entire file must fit in memory for a single digest() call.

The supported algorithms in Web Crypto for digest operations are: SHA-1, SHA-256, SHA-384, and SHA-512. MD5 is not available through Web Crypto (it was deliberately excluded due to its broken security status), so implementations that need MD5 must use a JavaScript polyfill or WebAssembly module.

All processing happens in the browser's main thread or a dedicated Web Worker. No network requests are made, no file contents leave the device, and no telemetry is collected about the files being hashed. This makes the tool suitable for verifying sensitive binaries, proprietary firmware, internal builds, or any file where privacy is a concern.

Difference from Text Hash Generation

This file checksum tool differs from the hash-generator tool on this site in a fundamental way: it operates on raw binary file data rather than text strings. When you hash a text string, the input is first encoded to bytes using a character encoding (typically UTF-8). The resulting hash depends on both the text content and the encoding used. Two different encodings of the same text (UTF-8 vs UTF-16) produce different hashes.

File checksums bypass this encoding step entirely — the file's raw bytes (as stored on disk) are fed directly into the hash function. This is essential for binary files (executables, images, archives) where there is no meaningful text representation. Even for text files, the file checksum captures the exact byte sequence including BOM markers, line endings (CRLF vs LF), and trailing whitespace — details that a text-oriented hasher might normalize or ignore.

Use the hash-generator when you need to hash a known string (API payload, password, message). Use this file-checksum tool when you need to verify the integrity of a downloaded file, compare two binary files for equality, or generate a fingerprint for content-addressable storage.

Code Examples

Computing a file SHA-256 checksum with Web Crypto API

// Compute SHA-256 checksum of a file using SubtleCrypto
async function computeFileChecksum(file, algorithm = 'SHA-256') {
  // Read file contents as ArrayBuffer
  const buffer = await file.arrayBuffer();

  // Compute the digest using Web Crypto API
  const hashBuffer = await crypto.subtle.digest(algorithm, buffer);

  // Convert ArrayBuffer to hex string
  const hashArray = Array.from(new Uint8Array(hashBuffer));
  const hashHex = hashArray
    .map(byte => byte.toString(16).padStart(2, '0'))
    .join('');

  return hashHex;
}

// Usage with a file input element
const input = document.querySelector('input[type="file"]');
input.addEventListener('change', async (event) => {
  const file = event.target.files[0];
  if (!file) return;

  const sha256 = await computeFileChecksum(file, 'SHA-256');
  console.log(`SHA-256: ${sha256}`);
  // → "e3b0c44298fc1c149afbf4c8996fb924..."

  const sha512 = await computeFileChecksum(file, 'SHA-512');
  console.log(`SHA-512: ${sha512}`);
});

Output:

SHA-256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
SHA-512: cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce...

Verifying a downloaded file against a known checksum

// Verify file integrity by comparing checksums
async function verifyFileIntegrity(file, expectedHash, algorithm = 'SHA-256') {
  const actualHash = await computeFileChecksum(file, algorithm);

  // Constant-time comparison to avoid timing side-channels
  if (actualHash.length !== expectedHash.length) return false;

  let mismatch = 0;
  for (let i = 0; i < actualHash.length; i++) {
    mismatch |= actualHash.charCodeAt(i) ^ expectedHash.charCodeAt(i);
  }

  return mismatch === 0;
}

// Example: verify a Linux ISO download
const expectedSha256 = 'a1b2c3d4e5f6...'; // from ubuntu.com/checksums
const isValid = await verifyFileIntegrity(downloadedFile, expectedSha256);

if (isValid) {
  console.log('✓ File integrity verified — safe to use');
} else {
  console.warn('✗ Checksum mismatch — file may be corrupted or tampered');
}

Standards & Specifications

• Web Crypto API — SubtleCrypto.digest() — MDN reference for the browser API used to compute SHA-256/384/512 digests from ArrayBuffer data
• FIPS 180-4 — NIST standard specifying the SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 hash algorithms
• W3C Web Cryptography API — W3C Recommendation defining the crypto.subtle interface for browser-native cryptographic operations
• RFC 6234 — US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) with test vectors for implementation verification