# File Checksum: SHA-256 and SHA-1

> Works out the SHA-256 and SHA-1 of a file in your browser, using the machine's own cryptographic library, and checks them against a checksum you paste in. The file is read in this tab and never sent anywhere.

Use it: https://tessalor.com/en/generators/file-checksum

This tool runs entirely in the browser. Nothing entered into it is uploaded.

## How it is done

1. Read the chosen file in this tab as raw bytes. Nothing is decoded, converted or altered, because a checksum is taken over the bytes exactly as they sit on disk.
2. Hand those bytes to the browser's own Web Crypto implementation with the algorithm name SHA-256, and read back the 32 bytes it returns.
3. Do the same again with SHA-1, which returns 20 bytes. Between the two the run hands control back so that Cancel works.
4. Write each digest as lower-case hexadecimal, two characters per byte, keeping the leading zero on any byte below sixteen.
5. Reduce the checksum you pasted to bare lower-case hex, dropping a "sha256:" label, surrounding whitespace, a trailing filename, or the spaces some tools print between byte pairs, then compare it against both digests.
6. Offer each digest as a one-line file laid out the way sha256sum writes one, so that "sha256sum -c" reads it back without complaint.

## Assumptions

- Both digests come from the browser's own Web Crypto implementation rather than from code on this page, so the figures are whatever the cryptographic library already on your machine produces.
- A matching checksum shows the file is byte for byte the one that was published. It says nothing about who published it, because anybody able to replace a download can replace the checksum listed beside it. Only a signature settles that.
- SHA-1 is here for checking against older published lists. Collisions have been demonstrated in practice since 2017 and NIST began retiring it in 2022, so a SHA-1 match is evidence against corruption rather than against tampering.
- The whole file is held in memory in this tab while it is hashed, which is why it is capped at 512 MB. Web Cryptography has no incremental digest, so there is no way to hash a larger file a piece at a time.
- The comparison ignores case, surrounding whitespace, an algorithm label and a trailing filename, because those are the shapes checksums are actually published in. It does not ignore anything inside the digest itself.

## Inputs

| Name | Label | Type | Default | Range |
| --- | --- | --- | --- | --- |
| `source` | File to check | file | chosen on your device | application/octet-stream, application/pdf, application/zip, application/gzip, application/json, application/x-tar, image/*, text/*, audio/*, video/*, up to 512 MB |
| `expected` | Checksum to check against | text |  |  |
| `letterCase` | Show the digests in | select | lower |  |

## Outputs

- `sha256` — SHA-256 (text), primary
- `sha1` — SHA-1 (text)
- `verdict` — Against the checksum you pasted (text)
- `size` — Bytes hashed (integer)

## Questions

### Is the file I am hashing uploaded anywhere?

No. The file is read in this browser tab and hashed by a worker running on your own machine. There is no server to send it to, and the automated test for this page fails if any request leaves this site while a file is loaded. That matters more here than on most pages, because the reason to checksum a file is that you do not yet trust it.

### Should I use the SHA-256 or the SHA-1?

Use the SHA-256 unless the checksum you were given is forty characters long, in which case it is a SHA-1 and that is the one to compare. Both are shown so you do not have to know which you were handed. If a publisher offers both, the SHA-256 is the one worth checking.

### The checksum I was given is in capitals. Does that matter?

No. Hexadecimal has no case, and the comparison lower-cases both sides before looking at them. Spaces between byte pairs, a leading "sha256:" and a filename after the digest are all ignored as well, because published checksums come in all of those shapes.

### The checksums do not match. What should I do?

Check the byte count first. If the size differs from the one the publisher lists, the download was truncated and simply needs fetching again, most often from a different mirror. If the size is right and the checksum is not, do not run the file. Fetch it again over a connection you control and compare once more before deciding anything.

### Does a matching SHA-256 mean the file is safe?

It means the file is byte for byte the one whose checksum you compared against. It does not mean the publisher is honest, and it does not help if the checksum came from the same page as the download, because anybody able to replace one can replace the other. A detached signature checked against a key you already had is what answers that question.

### Why is there no MD5?

Because the browser does not offer one. Web Cryptography registers four digest algorithms — SHA-1, SHA-256, SHA-384 and SHA-512 — and MD5 is not among them. Writing an MD5 by hand on a page whose whole job is producing a figure you can rely on is the wrong trade. If you have only an MD5 to compare against, use the md5sum or certutil already on your computer.

### Why does the progress bar jump rather than creep?

Because Web Cryptography has no incremental digest. It takes the whole input and returns the whole result, with no point in between at which a fraction can be read, so the bar moves once per algorithm instead of pretending to measure something. The native implementation is fast enough that a 512 MB file is a second or two of work.

## Sources

- [FIPS PUB 180-4: Secure Hash Standard (SHS)](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf) — National Institute of Standards and Technology, applies to 2015. Retrieved 2026-07-30.
- [RFC 3174: US Secure Hash Algorithm 1 (SHA1)](https://www.rfc-editor.org/info/rfc3174/) — IETF, applies to 2001; the test driver in section 7.3. Retrieved 2026-07-30.
- [Cryptographic Standards and Guidelines — Examples with Intermediate Values](https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/example-values) — National Institute of Standards and Technology, applies to SHA1.pdf and SHA256.pdf — the "abc" and 56-byte samples. Retrieved 2026-07-30.
- [FIPS PUB 180-2: Secure Hash Standard](https://csrc.nist.gov/files/pubs/fips/180-2/final/docs/fips180-2.pdf) — National Institute of Standards and Technology, applies to 2002, superseded; appendices A.3 and B.3, the one-million-byte vectors. Retrieved 2026-07-30.
- [Web Cryptography Level 2](https://www.w3.org/TR/webcrypto/) — W3C, applies to 2025. Retrieved 2026-07-30.
- [NIST Retires SHA-1 Cryptographic Algorithm](https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm) — National Institute of Standards and Technology, applies to 2022. Retrieved 2026-07-30.
- [GNU Coreutils manual: sha2 utilities](https://www.gnu.org/software/coreutils/manual/html_node/sha2-utilities.html) — GNU Project, applies to 2026. Retrieved 2026-07-30.

---

Estimate, not advice. See https://tessalor.com/en/disclaimer.
Machine-readable catalogue: https://tessalor.com/api/tools.json