Hash the bytes you downloaded
Calculate and compare a file checksum
Select a file up to 64 MiB, choose SHA-256, SHA-384, SHA-512, or MD5, and compare a complete expected hex or Base64 digest. The implementation buffers the entire file in browser memory.
Loading the file checksum calculator…
Enable JavaScript to read and hash a selected file locally. The verification guide remains readable below.
Verify bytes, not filenames
How to verify a downloaded file
- 1
Get a trusted expected value
Use the publisher's HTTPS site, signed release metadata, package registry, or another independent trusted channel. Record the algorithm with the digest.
- 2
Select the exact downloaded file
Hash the archive or installer named by the checksum list. Do not extract, rename content, open and resave it, or hash a shortcut that points elsewhere.
- 3
Compare the complete digest
Every hexadecimal digit must agree. A mismatch is a stop signal: obtain a fresh file and expected value instead of forcing the workflow to continue.
Deterministic integrity evidence
What a file checksum tells you
A file checksum is a digest calculated over the file's exact byte sequence. Two copies with identical bytes produce the same result under the same algorithm. An interrupted transfer, storage error, accidental edit, or different release normally changes the value dramatically. The filename, creation time, permissions, and directory location are not included unless they are themselves serialized inside an archive or other container.
SHA-256 produces 32 digest bytes displayed as 64 hexadecimal characters. SHA-384 and SHA-512 produce longer SHA-2 values. MD5 remains common in historical checksum lists, but its collision resistance is broken. SHA-1 is also obsolete for collision-sensitive use and is not offered by this calculator. Use MD5 only to match an unavoidable legacy value, not for a hostile security decision.
The expected digest is as important as the calculated one. A checksum copied from the same compromised server as the file does not independently establish origin. Prefer signed release manifests, package-manager signatures, reproducible-build attestations, or a value delivered through a separately trusted path when the consequence of installing a malicious file is high.
- Hashed input
- The exact bytes of the selected file.
- File limit
- 64 MiB, read completely into browser memory.
- Text mode
- Up to 5,000,000 UTF-16 code units.
- Match means
- The file agrees with the supplied digest under the selected algorithm.
- Match does not mean
- The checksum itself came from the claimed publisher.
Do not explain away a mismatch
Why file checksums differ
Wrong algorithmIdentify whether the expected value is MD5, SHA-256, SHA-384, or SHA-512 before comparing with this tool.Different release or mirrorConfirm version, architecture, build variant, and the exact checksum-list row.Interrupted transfer or error pageCheck the expected size and open only after a fresh trusted download verifies.Different bytes were hashedHash the original archive when that is what the published checksum names.Integrity versus provenance
A checksum is not publisher authentication
An unkeyed checksum lets anyone calculate the value for any file. That openness is useful for detecting accidental changes, but it means the digest contains no identity, secret, signature, expiry, or authorization. A malicious mirror can distribute a modified program and display the modified program's checksum beside it.
A digital signature binds data to a private signing key whose public counterpart you trust. Signed checksums or signed release manifests can authenticate many files efficiently, provided you verify the signature and key identity correctly. An HMAC authenticates to parties sharing one secret but does not provide public verifiability or non-repudiation.
Transport security such as HTTPS protects the connection to a server whose certificate is validated. It can make a checksum source trustworthy enough for some workflows, but it is not equivalent to a separately verifiable release signature. Choose assurance based on the damage a malicious file could cause.
Verify the publisher's signature and signing-key fingerprint, not only a checksum copied from a download page.
Read the complete verification workflow →Local calculation boundary
How local file hashing works here
The file picker grants this page access only to the file you select. The hashing code accepts files up to 64 MiB, reads the complete file into browser memory, and does not send those bytes to a LiveParse checksum endpoint. This is whole-file processing rather than streaming. A result can be copied after calculation, but selecting a file does not upload it.
Local does not mean the device is universally trusted. Browser extensions, endpoint monitoring, clipboard managers, malware, backups, and operating-system services may have separate access. Use a managed, trusted device for confidential artifacts and follow the owning organization's handling policy.
The optional text tab accepts at most 5,000,000 UTF-16 code units and hashes the current textarea value as UTF-8. Browser textarea or paste handling can normalize original CR or CRLF line endings to LF, so select the source file in file mode when original newline bytes matter. Native tools are a better fit for files larger than 64 MiB or automated batches.
- Selected file
- Read only after an explicit file-picker choice.
- Memory model
- The complete file is buffered; hashing is not streamed.
- Server upload
- Not used for the checksum calculation.
- Large or automated jobs
- Prefer an operating-system or build-pipeline hashing tool.
Questions answered
File checksum FAQ
How do I verify a file checksum?
Select the downloaded file, choose the algorithm named by the publisher, and compare the complete calculated digest with the expected value from a trustworthy channel. A match requires every hexadecimal digit to agree.
Which file checksum algorithm should I choose?
Use the exact supported algorithm that produced the expected value. For a new general integrity workflow, SHA-256 is a broadly supported default. Do not substitute MD5 when collision resistance against attackers matters.
Does a matching checksum prove the file is authentic?
Not by itself. It proves that the file bytes match the expected digest, but a malicious source may replace both an unauthenticated file and checksum. Obtain the checksum independently or verify a trusted digital signature when publisher identity matters.
Why does my checksum not match?
Common causes are a different file version, incomplete or corrupted download, hashing a compressed archive instead of its extracted contents, using the wrong algorithm, or comparing against a checksum copied with extra labels or characters.
Are uppercase and lowercase hexadecimal checksums different?
No. Hexadecimal A through F may be written in either case without changing the digest bytes. Whitespace and common separators can be normalized for display, but the full sequence of hexadecimal digits must still match exactly.
Is the selected file uploaded?
No. The browser reads and hashes the selected file locally; its contents are not sent to a file-checksum API. The operating system file picker, browser extensions, and other software on the device remain separate privacy boundaries.
What are the file checksum input and memory limits?
Files are limited to 64 MiB and are read completely into browser memory before hashing, so this calculator is not streaming. Its optional text mode is limited to 5,000,000 UTF-16 code units.
Does the optional text mode preserve original newline bytes?
Not necessarily. Text mode hashes the current textarea value as UTF-8, and browser textarea or paste handling can normalize original CR or CRLF line endings to LF. Select the source file in file mode to preserve its original newline bytes.