, `$2b , `$2x , `$2y all parse correctly via bcryptjs. The cost factor and salt are extracted automatically, and verification uses the standard bcrypt KDF regardless of prefix."}},{"@type":"Question","name":"What does the length-mismatch hint mean?","acceptedAnswer":{"@type":"Answer","text":"You pasted a hash whose length does not correspond to any supported algorithm. MD5 is 32 hex / 24 base64; SHA-1 is 40 / 28; SHA-256 is 64 / 44; SHA-512 is 128 / 88; bcrypt is exactly 60 chars including the prefix. The hint tells you which algorithms could have produced your expected length — most often this means you copied a partial hash or used an unsupported algorithm like Blake2."}},{"@type":"Question","name":"Can I check multiple algorithms at once?","acceptedAnswer":{"@type":"Answer","text":"Yes — that is the whole point of the verifier. All five algorithms run in parallel against your input. You only need one expected-hash value; the matching algorithm row turns green and the rest stay neutral or red."}},{"@type":"Question","name":"How large a file can I check?","acceptedAnswer":{"@type":"Answer","text":"5 MiB. Larger files are rejected — for gigabyte-scale checking use `sha256sum` on Linux, `shasum -a 256` on macOS, `Get-FileHash -Algorithm SHA256` on Windows PowerShell, or `certutil -hashfile SHA256` on Windows cmd."}},{"@type":"Question","name":"Is file integrity check the same flow as password verification?","acceptedAnswer":{"@type":"Answer","text":"No — file integrity uses a content digest (MD5/SHA family); password verification uses bcrypt with a candidate password. Both use the same UI but the input semantics differ: for file integrity you hash the file and compare; for bcrypt you give the candidate password and the stored hash, and the bcrypt algorithm internally extracts the salt and cost factor."}},{"@type":"Question","name":"Is the file uploaded?","acceptedAnswer":{"@type":"Answer","text":"Never. The FileReader API reads the file bytes into the browser; the digest is computed via `crypto.subtle.digest` (SHA family) or spark-md5 (MD5). No outbound request is made. You can disconnect from the network and the verifier still works."}},{"@type":"Question","name":"Where can I read the standards?","acceptedAnswer":{"@type":"Answer","text":"RFC 1321 (MD5), RFC 6234 (SHA-1, SHA-256, SHA-512), NIST FIPS 180-4 (SHA family), and the bcrypt original paper (Provos & Mazières 1999). MDN has practical Web Crypto examples for `crypto.subtle.digest`."}}]}

Hash Checker

0 chars· or drag a file here

Paste an expected hash and your input to verify.

About the Hash Checker

The Hash Checker is the verify-first counterpart to the Hash Generator. Drop a file (up to 5 MiB) or paste text, paste an expected hash, and every supported algorithm — MD5, SHA-1, SHA-256, SHA-512, bcrypt — runs in parallel against your input. Whichever algorithm matches lights up green; mismatches go red. The tool surfaces which algorithm produced the expected value, which is essential when a release page just gives you a bare hash without telling you whether it is SHA-256 or SHA-512. Everything runs locally; the file you check stays in your tab, and the expected hash never gets logged anywhere.

Updated: May 8, 2026

Related Tools

Hash GeneratorCompute a hash side-by-side with verification — the canonical hash workflow.Try it SHA-256 GeneratorAlgorithm-specific landing for the most common modern digest.Try it MD5 GeneratorLegacy checksum verification when the publisher used MD5.Try it bcrypt HashGenerate bcrypt hashes when you need test fixtures alongside verification.Try it UUID GeneratorGenerate stable test IDs to pair with hashed test fixtures.Try it

How to use the hash checker

  • Drop a file or paste text into the input area. Files up to 5 MiB hash in well under a second on modern hardware via Web Crypto.
  • Paste the expected hash into the "Compare with expected hash" field. Hex (lowercase or uppercase) and Base64 are both accepted; whitespace around the value is tolerated.
  • Each algorithm row updates immediately: green badge if the computed digest equals the expected value, red if it differs. The green row is the algorithm the publisher used.
  • For bcrypt, paste the full modular-crypt format string (`$2a$10
    lt;22-char-salt><31-char-hash>`) and the candidate password — bcrypt verification uses `bcryptjs.compare` which handles the salt extraction internally.
  • Length-mismatch hint: if your expected hash length does not correspond to any supported algorithm (32 hex / 16 bytes for MD5, 40 hex / 20 bytes for SHA-1, 64 hex / 32 bytes for SHA-256, etc.), the tool surfaces a hint so you do not waste time wondering why nothing matches.

Common use cases

  • Download integrity verification. Apache, Linux distributions, Docker, GitHub release pages, and HashiCorp project downloads publish digests next to release artifacts. Drop the artifact + paste the published hash — the matching algorithm row turns green and you know the bits are intact.
  • Git object lookup. Git uses SHA-1 (and is migrating to SHA-256). Paste a Git commit ID or blob hash and check it against your local copy.
  • TLS certificate fingerprint matching. `openssl x509 -fingerprint -sha256` produces a colon-separated hex digest; paste it here against your downloaded certificate and confirm the fingerprint pinning.
  • bcrypt password verification. During development or migration scripts, drop the production bcrypt hash + a candidate password to confirm whether the candidate matches without needing a server round-trip.
  • Forensic chain-of-custody. SHA-256 digests of evidence files preserve a tamper-evident record. The verifier confirms a candidate file matches the recorded hash without uploading evidence to any third-party scanner.

Privacy and security

Hashing happens in your browser via Web Crypto (`crypto.subtle.digest` for SHA family) and the lazy-loaded spark-md5 + bcryptjs modules. Files are read with the FileReader API; bytes never leave the page. Expected-hash input is never URL-synced or logged. Disconnect from the network and the verifier still works — useful for verifying hashes of files that should not be exposed to a network at all (forensic evidence, signed contracts, internal-only releases).

Tips and pitfalls

  • Hex vs Base64 confusion. The same digest can be represented as 64 hex characters (for SHA-256) or 44 Base64 characters. Some CDNs use Base64 in their `Subresource-Integrity` directive; many publishers use hex. The verifier accepts both — but make sure you copy the full string.
  • Whitespace is tolerated. Pasting from email or a release page often introduces leading/trailing spaces or stray newlines. The verifier strips them automatically.
  • Case-insensitive hex matching. `ABC123` and `abc123` are equivalent in hex; the verifier normalizes both sides before comparing.
  • bcrypt prefix variants. The bcrypt modular-crypt format has four prefix variants (`$2a toolrunner , `$2b toolrunner , `$2x toolrunner , `$2y toolrunner ); all four are recognized and verified using the same algorithm. The differences are historical implementation details that do not affect verification.
  • Length mismatches usually mean wrong algorithm. If you paste a 64-character hex string but the publisher used SHA-512 (128 hex), the length-mismatch hint will tell you to look for SHA-256 instead.

Frequently Asked Questions

How do I verify a download integrity?
Drop the downloaded file. Paste the publisher's hash. The algorithm that matches lights up green. If nothing matches, either the file is corrupted, you copied the wrong hash, or the publisher used an unusual algorithm (Blake2, SHA-3) we do not support.
Hex or Base64 — which encoding should I paste?
Either works. Most release pages use lowercase hex. SRI directives (`integrity="sha384-..."`) use Base64. The verifier auto-detects encoding by length and alphabet, normalizes whitespace and case, and compares.
Does it recognize all bcrypt variants?
Yes — `$2a toolrunner , `$2b toolrunner , `$2x toolrunner , `$2y toolrunner all parse correctly via bcryptjs. The cost factor and salt are extracted automatically, and verification uses the standard bcrypt KDF regardless of prefix.
What does the length-mismatch hint mean?
You pasted a hash whose length does not correspond to any supported algorithm. MD5 is 32 hex / 24 base64; SHA-1 is 40 / 28; SHA-256 is 64 / 44; SHA-512 is 128 / 88; bcrypt is exactly 60 chars including the prefix. The hint tells you which algorithms could have produced your expected length — most often this means you copied a partial hash or used an unsupported algorithm like Blake2.
Can I check multiple algorithms at once?
Yes — that is the whole point of the verifier. All five algorithms run in parallel against your input. You only need one expected-hash value; the matching algorithm row turns green and the rest stay neutral or red.
How large a file can I check?
5 MiB. Larger files are rejected — for gigabyte-scale checking use `sha256sum` on Linux, `shasum -a 256` on macOS, `Get-FileHash -Algorithm SHA256` on Windows PowerShell, or `certutil -hashfile <file> SHA256` on Windows cmd.
Is file integrity check the same flow as password verification?
No — file integrity uses a content digest (MD5/SHA family); password verification uses bcrypt with a candidate password. Both use the same UI but the input semantics differ: for file integrity you hash the file and compare; for bcrypt you give the candidate password and the stored hash, and the bcrypt algorithm internally extracts the salt and cost factor.
Is the file uploaded?
Never. The FileReader API reads the file bytes into the browser; the digest is computed via `crypto.subtle.digest` (SHA family) or spark-md5 (MD5). No outbound request is made. You can disconnect from the network and the verifier still works.
Where can I read the standards?
RFC 1321 (MD5), RFC 6234 (SHA-1, SHA-256, SHA-512), NIST FIPS 180-4 (SHA family), and the bcrypt original paper (Provos & Mazières 1999). MDN has practical Web Crypto examples for `crypto.subtle.digest`.