How can your browser calculate two hashes from one file read?

A download page may ask for a SHA-256 or SHA-512 checksum—a fingerprint of the file. FluffyBench can calculate both while reading your file just once.

FluffyBench · 4 min read · Measured October 13, 2026 with FluffyBench Hash Checksum

How one file stream feeds two checksum calculations

Imagine reading a long letter aloud while two people listen and take notes by different rules. You don't have to start over for the second listener. Both hear the same words as you go.

FluffyBench Hash Checksum does something similar: it reads your file in pieces and sends each piece to both SHA-256 and SHA-512. Those are two different recipes for making a file's fingerprint, called a checksum or digest.

One file stream supplies pieces in order to separate SHA-256 and SHA-512 calculations. Both produce fingerprints after the last piece. — Application-level data flow: the same pieces feed two separate calculations. How we reviewed

Why does a file get both SHA-256 and SHA-512 checksums?

A download publisher may give you either kind of checksum. Having both ready means you can use whichever recipe the publisher names, without choosing it before you open the file.

Here's dahlia-close-up.jpg in FluffyBench Hash Checksum, with its two fingerprints. Compare a publisher's SHA-256 reference with SHA-256, or a SHA-512 reference with SHA-512.

Workspace excerpts showing dahlia-close-up.jpg, Checksums, Both are made in one read, and its complete SHA-256 and SHA-512 results. — Workspace excerpts from the same photo: each checksum recipe has its own result. · Photo: Tj Holowaychuk, Unsplash License, via Unsplash.

Doing it in FluffyBench: check a downloaded file

Use FluffyBench Hash Checksum to compare your download with a trusted reference. The dahlia photo below makes the steps concrete.

Step 1. Choose your downloaded file. FluffyBench starts calculating as soon as you select it; the file stays on your device.
1. Use File for a download.
2. Choose file opens your file picker.
Step 2. Check that you've selected the right download.
1. Check the filename against your download.
2. Change file lets you replace a wrong selection.
Step 3. Paste the checksum from a publisher you trust for that exact download. Its length picks SHA-256 or SHA-512 automatically. Here we're using the photo's independently calculated reference.
1. Expected checksum takes the reference value.
2. It matches means the complete values agree.
Step 4. The matching algorithm's row is highlighted. If you need the fingerprint as text, use Copy beside its name.
1. This highlighted SHA-256 value matches the reference.
2. Copy SHA-256 copies the complete SHA-256 value.
3. The SHA-512 row keeps its separate result.

A match means the file agrees with the reference. It doesn't identify the publisher or tell you whether the download is safe to open; our guide to checksums and digital signatures explains that distinction.

How long did both file checksums take on a desktop?

We timed generated files held in memory on a desktop. Each bar measures the wait from choosing a file until both checksums were ready.

Time until both checksums are ready: 1,250 ms

Chrome · 1.0 MB: 15.2 ms
Firefox · 1.0 MB: 15 ms
Chrome · 16.8 MB: 146.4 ms
Firefox · 16.8 MB: 163 ms
Chrome · 134.2 MB: 880.3 ms
Firefox · 134.2 MB: 1,212 ms

0 ms250 ms500 ms750 ms1,000 ms1,250 ms

Chrome · 134.2 MB
The largest input's Chrome result.
Firefox · 134.2 MB
The same input's Firefox result.

Each file-size pair shows the middle time for Chrome and Firefox.

Even the largest input, 134.2 MB, finished in under a second in Chrome and just over a second in Firefox on that desktop. You can use the result as soon as both checksum lines appear.

How we reviewed

Reviewed October 13, 2026

Chrome 153.0.8010.12 and Firefox 155.0. AMD Ryzen 9 5950X; 127.9 GiB RAM; Windows 11 Pro. Build: 5dfc1557.

SHA-256 and SHA-512 were updated for each file piece, using one file stream reader in the application.

Generated, memory-backed files of 1,048,576 bytes, 16,777,216 bytes, and 134,217,728 bytes, filled with 0x5A; the same archived bytes were used for independent digest verification. 3 runs per size and browser.

Every displayed SHA-256 and SHA-512 result in the timing run matched an independent calculation over the archived input bytes. The photo example and walkthrough use the same archived dahlia photo; its expected checksum was calculated independently for illustration.

The timer began at the file selection change event and ended when both digests were available. It excluded File construction, navigation, and independent verification. Bars show medians, or middle times; sizes use decimal MB, and timing values use milliseconds.

1.0 MB observed range: Chrome 10.9 ms–23.9 ms; Firefox 14 ms–18 ms.

16.8 MB observed range: Chrome 136.1 ms–146.5 ms; Firefox 154 ms–168 ms.

134.2 MB observed range: Chrome 836.6 ms–909.4 ms; Firefox 1,207 ms–1,213 ms.

The viewport was 1,440 px by 1,000 px; no separate warm-up was used.

We didn't time either algorithm alone or two separate file reads, so the timings don't measure a speed saving. Physical disk reads, browser process, renderer and heap memory, and cancellation timing were not measured; reading in pieces doesn't by itself establish a memory bound. Results describe the recorded build, hardware, and browser pair.

Image credits

Macro shot photo of orange flower — Tj Holowaychuk. Unsplash License. Used as a local file input for the live checksum-tool capture; the displayed file name is dahlia-close-up.jpg.