File checksums

What the number is

SHA-256 reads a file as a stream of bytes and reduces it to 32 bytes, usually written as 64 hexadecimal characters. The reduction is one-way and highly sensitive: changing a single byte anywhere in the file produces a completely different digest, with no visible relationship to the original.

Two identical files always produce the same digest, on any machine and in any browser. That is the whole idea — the digest travels cheaply (it is 64 characters), while the file may be gigabytes.

Using the tool

1. Open rose.wool.win and stay on the File checksum tab.
2. Click the drop zone to pick a file, or drag the file onto it.
3. The badge reports progress while the digest is computed, then shows how long it took. The digest appears in the result box in lowercase hex.
4. Optionally paste the published digest into Expected SHA-256. Rosehip strips a leading sha256:, spaces and colons, ignores case, and then reports checksum matches or checksum does not match.

If the expected value is not 64 hexadecimal characters, the tool says so instead of guessing — a truncated paste is the most common reason for a false alarm.

How the file is read

Files up to 256 MB are hashed with the browser's native Web Crypto implementation, which is fast and uses the platform's optimised code. Larger files are streamed in 8 MB chunks through a small built-in SHA-256, so memory use stays flat instead of growing with the file; the trade-off is speed. In both cases the bytes are read from a local file handle and never leave the tab.

Verifying a download

1. Find the digest the publisher lists for the exact file you downloaded. Make sure the name, version and architecture match; digests for setup-x64.exe and setup-arm64.exe are different files' digests.
2. Hash your local copy with Rosehip.
3. Paste the published value into the expected field and compare.

If the digests differ: download the file again (an interrupted transfer is the usual cause), check that you hashed the file rather than a shortcut or a partially unpacked copy, and confirm that the published digest really belongs to that build. Do not skip the check just because the download completed.

What a match proves, and what it does not

A match proves that the file you hashed is byte-for-byte the file whose digest you were given. It does not prove that the file is safe, that it came from the publisher, or that the digest itself was not tampered with. If the digest and the file were both served from the same compromised page, they will agree.

Treat the checksum as an integrity check, not as a signature. Where a publisher offers a signature, verify the signature as well.

Common reasons for a mismatch

• A different build. Two installers with the same visible version but different targets, bundlers or release channels have different digests.
• Transfer damage. An interrupted or proxied download can produce a file of the right size with the wrong bytes.
• Text files that were converted. A CSV or script converted between CRLF and LF line endings, or saved with a byte-order mark, is a different file.
• An archive versus its contents. A .zip and the folder you extracted from it are not the same input.
• Editing after hashing. Resaving a document, even without visible changes, changes its bytes.

A worked example

The SHA-256 of an empty file is a well-known constant:

e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Create an empty file, hash it, and you should get that value back. It is a useful sanity check that the tool is working and that you are hashing the file you think you are.

Checking the same thing in a terminal

On macOS, Linux and most BSD systems the digest is also available from the command line. If the values agree, the browser and the shell are looking at the same bytes:

sha256sum ./file.zip        # Linux
shasum -a 256 ./file.zip    # macOS