Checksum Calculator
Compare MD5, SHA-1, SHA-256, and SHA-512 hash algorithms. Learn when each is appropriate, why MD5 is insecure, and how to verify file integrity using checksums.
Hash Output Length (bits)
—
Hex Characters —
Security Status —
Extended More scenarios, charts & detailed breakdown ▾
Hash Bits
—
Hex Char Count —
Possible Hash Values (2^n) —
NIST Status —
Professional Full parameters & maximum detail ▾
Algorithm Selection
Recommended Algorithm —
Hash Output (bits) —
NIST Status —
Implementation Details
Salt Required? —
Est. Compute Time per Hash —
How to Use This Calculator
- Select the Algorithm (SHA-256 recommended for most uses).
- See hash output length, hex character count, and NIST security status.
- Use the Text Input tab to understand hash properties for a given input length.
- Use the File Hash Info tab to find the right OS command to hash a file.
- Use Professional to get algorithm recommendations per use case.
Formula
MD5: 128-bit → 32 hex chars
SHA-1: 160-bit → 40 hex chars
SHA-256: 256-bit → 64 hex chars
SHA-512: 512-bit → 128 hex chars
Example
SHA-256("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824. Change to "Hello" and the entire output changes — the avalanche effect.
Frequently Asked Questions
- The terms checksum and hash are often used interchangeably, but technically they have different origins. A checksum is a simple error-detection value — originally a sum of all bytes in a file, used to catch accidental corruption during transmission. Basic checksums like CRC32 are fast but not designed to detect intentional tampering. A cryptographic hash function is much more sophisticated: it takes an input of any length and produces a fixed-size output (digest) that has specific security properties — it is one-way (you cannot reverse it to find the input), deterministic (same input always produces the same output), and exhibits the avalanche effect (changing even one bit of input completely changes the output). SHA-256 produces 256-bit (64 hex character) digests. In practice, "checksum" and "hash" are used synonymously in file verification contexts — software distributors publish SHA-256 or MD5 hashes alongside downloads so users can verify the file has not been corrupted or tampered with.
- MD5 was designed in 1991 and was widely used for decades, but it has two fundamental cryptographic weaknesses that make it unsuitable for security purposes today. First, MD5 is vulnerable to collision attacks — researchers can deliberately construct two different inputs that produce the same MD5 hash. In 2008, a team demonstrated creating rogue SSL certificates using MD5 collisions, and by 2012 the Flame malware used forged MD5 certificates to impersonate Microsoft Windows Updates. Second, MD5 is a very fast algorithm — a modern GPU can compute billions of MD5 hashes per second, making brute-force password attacks trivial. RFC 6151 formally deprecated MD5 for security use in 2011. MD5 remains acceptable for non-security purposes like detecting accidental file corruption or generating cache keys, where collision attacks are not a concern. For any security application — file integrity verification against adversaries, digital signatures, or password storage — SHA-256 or stronger is the minimum acceptable standard.
- When you download software or important files, the provider typically publishes a SHA-256 or SHA-512 hash alongside the download link. After downloading, you compute the hash of your downloaded file using a command-line tool and compare it to the published value. On Linux and macOS: run sha256sum filename.iso in a terminal. On Windows: use PowerShell command Get-FileHash filename.iso -Algorithm SHA256. If the computed hash exactly matches the published hash, the file is bit-for-bit identical to what the provider published — it has not been corrupted or modified. This protects against accidental download corruption, man-in-the-middle injection, and mirror server compromise. However, hash verification alone does not prove the software itself is safe — it only proves it matches what the publisher distributed. For complete authenticity, the hash should itself be digitally signed with the publisher's GPG private key, allowing you to verify both integrity and publisher identity.
- A salt is a random value added to a password before hashing, ensuring that even identical passwords produce different hash outputs in a database. Without salting, an attacker who steals a password database can use precomputed rainbow tables — massive lookup tables mapping common passwords to their hashes — to instantly crack millions of passwords. With salting, each password gets a unique random salt (typically 16–32 bytes) stored alongside the hash. Even if two users have the same password "password123", their stored hashes are completely different because each has a unique salt. Modern password hashing algorithms like bcrypt, scrypt, and Argon2id incorporate salting automatically and are intentionally slow — designed to take 100–1000 milliseconds per hash — making large-scale brute-force attacks economically impractical. OWASP recommends Argon2id as the first choice for new systems, with bcrypt as a widely supported alternative. Never use raw SHA-256 or MD5 for password storage, even with salting — they are too fast.
- Git uses SHA-1 to generate unique identifiers for commits, trees, blobs, and tags — not for cryptographic security or authentication. A Git SHA-1 hash is a content-addressable name: the same file content always produces the same hash, allowing Git to detect accidental corruption and efficiently deduplicate stored objects. Git has never claimed SHA-1 provides cryptographic authentication — it does not prevent a malicious actor with write access to a repository from replacing objects. The 2017 SHAttered attack demonstrated SHA-1 collision construction, which could theoretically allow two different files to have the same Git hash. In response, Git has been transitioning to SHA-256 object names since version 2.29 (2020), though SHA-1 remains the default for compatibility with existing repositories and hosting platforms. GitHub announced SHA-256 migration plans. The practical security risk from SHA-1 in Git is low because Git relies on access controls (SSH keys, tokens) rather than hash security to prevent unauthorized writes, and SHA-1 collision construction requires enormous computational resources.