Does the file get uploaded?

No. Hashing uses the Web Crypto API on a streamed FileReader, so even multi-gigabyte files are processed locally without ever leaving your device.

Which checksum should I compare against?

Use the strongest one the publisher provides. SHA-256 is the modern standard. SHA-1 and MD5 are still common on legacy projects but only confirm transfer integrity, not authenticity against a malicious mirror.

Why are all four hashes shown?

Different projects publish different digests. Computing them in one pass lets you compare against whichever checksum the source provides without re-reading the file.

md5 · sha1 · sha256 · sha512 · local

Verify file checksums locally

Drag any file in and get MD5, SHA-1, SHA-256, and SHA-512 simultaneously. Compare against vendor checksums. Runs entirely in your browser.

File Checksum Verifier

File

—

drop a file

Size

—

Algos

—

md5/sha1/256/512

Status

idle

web crypto

input · file

MD5 is for cross-checks only — broken cryptographically. Prefer SHA-256 or SHA-512 for trust decisions.

output · digests

md5

…

sha1

…

sha256

…

sha512

…

Drop a file to compute checksums

Quick Start

How to verify a file checksum

The browser reads the file into memory and runs MD5, SHA-1, SHA-256, and SHA-512 in parallel. Compare against the published checksum from your vendor.

01
Drop a file
Any file — text, binary, archive. Loaded once into memory.
Bytes flow through TextEncoder/TextDecoder for predictable UTF-8 semantics — emoji, surrogate pairs, and combining marks all encode losslessly.
inputUTF-8TextEncoderlosslesslive
input · raw bytesfile · UTF-8
```
ubuntu-22.04.iso
```
loaded · UTF-8MIME · ready
02
Wait for digests
Four algorithms run in parallel — usually subsecond for files under 100MB.
Hash and signature operations call crypto.subtle from the Web Crypto API, so output matches OpenSSL / Node bit-for-bit.
computeWeb Cryptosubtledeterministiclive
alg · optionsx4 · live
```
md5 · sha1 · sha256 · sha512
```
options applied · livelive
03
Compare
Paste the vendor's published digest, eyeball or text-diff against the matching row.
Options re-run instantly through useEffect + useMemo — switching URL-safe mode or padding doesn’t re-encode from scratch.
verifymemoisedoptionsinstantreactive
match · encoded✓ · ready
```
expected == actual
```
encoded · livelossless
04
Copy digest
One click copies the chosen hash for inclusion in release notes or scripts.
Copy uses the Async Clipboard API; downloads ship via Blob with the appropriate MIME (text/plain, image/png, …) so external tools recognise them.
exportclipboardblobMIME-correctclient-side
ok · copiedready · done
```
Copied SHA-256
```
shipped · ready to shipsuccess

Pro tips

Encoding without surprises

Always UTF-8 first

Use TextEncoder / TextDecoder for bytes ↔ string conversion. btoa alone breaks on non-ASCII.

URL-safe vs standard Base64

Standard uses +, /, =; URL-safe swaps to -, _, no padding. Don’t mix them.

Hashes aren’t passwords

SHA-256 is fast; that’s good for fingerprints, bad for passwords. Use bcrypt / argon2 for credentials.

Watch padding rules

Some decoders are strict about = padding, others auto-pad. If round-trips fail at exactly 1 or 2 bytes, check padding.

Use Web Crypto for keys

Generate cryptographic keys via crypto.subtle, never Math.random. The latter is predictable.

JWT decode ≠ verify

Decoding a JWT just splits and base64-decodes. Verification needs the issuer’s public key / shared secret.

Use Cases

When to verify checksums

Downloads, releases, supply-chain integrity.

ISO / installer downloads

Confirm a Linux ISO or vendor installer is unaltered. Output round-trips losslessly with the matching decoder — both run client-side, so end-to-end testing happens in a single tab. Encoding flows through TextEncoder for predictable UTF-8 semantics.

RFC-compliant

Release artifacts

Spot-check the npm / Maven / PyPI tarball against publisher's SHA-256. Web Crypto's subtle.digest produces output that matches OpenSSL, GPG, and Node's crypto module byte-for-byte. That makes the result trustworthy as a content fingerprint, ETag, or integrity check.

OpenSSL-matched

Backups

Confirm a long-term archive hasn't bit-rotted. Pairs cleanly with HMAC, JWT, and signed-URL workflows where bit-level correctness matters. The browser's crypto stack is FIPS 140-validated in Chrome and Firefox, so it's production-grade.

lossless

Build reproducibility

Compare hashes of two builds to detect non-determinism. Output uses canonical RFC 4648 / 7515 alphabets so curl, openssl, and any standards-compliant decoder accept it as input. URL-safe variants drop padding for tokens that travel in query strings.

byte-identical

Forensics

Lock down original-file hashes early in an investigation. Heavy hashing runs through useMemo so large inputs don't block typing. PBKDF2, bcrypt, and Argon2 expose configurable cost factors — tune for your threat model, not the default.

spec-grade

Subresource integrity

Generate SHA-256 / SHA-384 / SHA-512 for SRI attributes. Same input plus same options always yields identical bytes. That's the foundation for content-addressed storage (IPFS, Git, S3 ETags) and means the output is safe to commit to fixtures.

production-ready

FAQ

Frequently asked questions

Is the file uploaded anywhere?

No. The file is read into the browser's memory and hashed locally — nothing leaves your machine.

Which algorithm should I trust?

SHA-256 is the modern default. MD5 and SHA-1 are still useful for cross-checks but are broken cryptographically.

How large a file can I hash?

Limited by browser RAM. Several hundred MB usually fine; multi-GB may run out of memory.

Why does the hash differ from openssl?

Make sure you're comparing to the same algorithm and no extra newline was appended to the file. The hex strings should match exactly.

Is anything sent to a server?

No. Hashing uses Web Crypto plus a pure-JS MD5 — all runs locally in your browser.

Suggest a tool

Something missing?

Tell us what you need. We ship the top requests every two weeks.

47 in queue·8 shipped this month

Request queued. Thanks!