How to check a firmware image's sha-256 before you flash it
- Step 1Download the firmware and find its published checksum — Get the image (
.bin,.img, BIOS/UEFI update, router/IoT payload) from the vendor, and locate the checksum they published next to it — asha256value, aSHA256SUMSfile, a release-notes MD5, or a.sha512file. - Step 2Fingerprint the downloaded image — Drop the firmware file and run. Its bytes are read into memory and digested locally with MD5, SHA-1, SHA-256, and SHA-512. Don't unzip or modify the image first — hash exactly the file the vendor checksummed.
- Step 3Pick the line that matches the published format — If the vendor published SHA-256, read the report's
sha256; if MD5, readmd5; if SHA-512, readsha512. Match digest length to format: 64 hex chars is SHA-256, 32 is MD5, 128 is SHA-512, 40 is SHA-1. - Step 4Compare character-for-character before flashing — Match the relevant digest against the vendor's value, case-insensitively (hex is case-insensitive, and many vendors print uppercase). Match: the image is intact and safe to flash. Mismatch: do not flash — re-download from the official source.
- Step 5Verify the publisher when a signature is provided — If the vendor signs their checksums (a
.asc/.sig), verify that signature too — a checksum only proves the bytes match a published value, not that an attacker didn't replace both. Use a PGP verifier for the signature; a hash for the bytes. - Step 6Flash, then optionally re-verify the on-device readback — Flash only after the hash matches. If your flasher can read the image back, fingerprint the readback and confirm the SHA-256 still matches the source — proof the write landed byte-for-byte.
Match the vendor's checksum format to the report line
Firmware vendors publish checksums in different shapes. Whichever they used, the matching algorithm is already in the report.
| Vendor publishes… | It's this algorithm | Match the report's… |
|---|---|---|
A sha256 value or SHA256SUMS file | SHA-256 | sha256 (64 hex chars) |
| An MD5 in the release notes or on the page | MD5 | md5 (32 hex chars) — corruption check only |
A .sha512 file or a 128-char block | SHA-512 | sha512 (128 hex chars) |
| A 40-char hex value | SHA-1 | sha1 (40 hex chars) — corruption check only |
A .asc / .sig next to the image | Not a hash — a PGP signature | Verify with pgp-message-signer |
Why verify before flashing — the failure a size check misses
What different signals tell you about a firmware download, and why only the hash is decisive before a write.
| Check | Catches | Misses |
|---|---|---|
| File size matches | Wholesale truncation (very short file) | A flipped bit, a partial overwrite, a same-size wrong build |
| File opens / flasher accepts it | Some format problems | Corruption the format header doesn't cover |
| SHA-256 matches vendor checksum | Any byte-level difference, anywhere in the image | Whether the *publisher* is authentic (use a signature for that) |
Limits and scope
Per-image, in-memory hashing. The cap is your tier's security file-size limit; large images may need a higher tier or a CLI checksum.
| Property | Value | Notes |
|---|---|---|
| File-size limit (Free / Pro / Pro-media / Developer) | 10 MB / 100 MB / 500 MB / 2 GB | Whole image read into memory; a file over your cap is rejected before hashing |
| Files per run | 1 (the first dropped file) | Verify one image per run |
| Input | Any file (raw bytes) | .bin, .img, BIOS update, router/IoT payload — hash the file as the vendor published it |
| Output | JSON { sha1, sha256, sha512, md5 }, lowercase hex | Copy the sha256, or download <filename>.hashes.json |
Cookbook
Pre-flash verification recipes. The tool gives you the four digests; the safety comes from matching the right one to the vendor's checksum before you write. CLI equivalents let you cross-check from a terminal.
Verify a router firmware against the vendor's SHA-256
Before flashing a new router image, confirm its SHA-256 equals the value on the vendor's download page. A match means the download is bit-identical to the release; flash it. A mismatch means re-download.
Report (sha256): e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 Vendor page: SHA-256: E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855 Match (hex is case-insensitive) -> safe to flash. Terminal: sha256sum router-fw-2.1.4.bin
Check a BIOS/UEFI update before applying it
Motherboard vendors publish a checksum for each BIOS file. Fingerprint the downloaded update and match it before you run the flasher — a corrupt BIOS write is among the riskiest failures there is.
Report sha256: b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c Vendor checksum file (BIOS_F12.sha256): b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c BIOS_F12.bin Match -> apply the update. Windows cross-check: certutil -hashfile BIOS_F12.bin SHA256
Match a legacy device that only publishes MD5
Older or niche IoT vendors sometimes only list an MD5. MD5 is collision-broken for security, but for catching a corrupted download from the official source it still confirms the bytes are intact. The matching md5 line is in the report.
Report md5: 9e107d9d372bb6826bd81d3542a419d6 Vendor download note: MD5 9E107D9D372BB6826BD81D3542A419D6 Match -> download not corrupted. (Still prefer SHA-256 when the vendor offers it; MD5 can't defend against a deliberately swapped image.)
Confirm the on-device write landed correctly
If your flasher can read the image back from the chip, fingerprint the readback and compare it to the source image's SHA-256. Identical digest proves every byte was written correctly — verification that goes beyond the flasher's own 'done' message.
Source image -> sha256: 2c26b46b68ffc68ff99b453c1d304134...
Readback dump -> sha256: 2c26b46b68ffc68ff99b453c1d304134...
Identical -> the flash is verified byte-for-byte.
Differ -> the write was incomplete or the readback differs;
re-flash before rebooting the device.Catch a same-size but corrupted download
A flaky download can produce a file with the correct size but a flipped bit inside — a size check passes, the flasher might too, and the device bricks. The SHA-256 won't match the vendor's, catching the problem before any write.
Expected (vendor) sha256: 7d865e959b2466918c9863afca942d0f... Your download sha256: 5f4dcc3b5aa765d61d8327deb882cf99... File size: identical on both. Hash differs despite same size -> download is corrupt. Do NOT flash; re-download from the official source.
Edge cases and what actually happens
Hash matches but the image is from an untrusted mirror
Authenticity not provenA checksum match only proves the bytes equal a *published* value. If an attacker controls the mirror, they can post a malicious image and a matching checksum. A hash does not authenticate the publisher. For untrusted sources, verify the vendor's PGP signature over the checksum with pgp-message-signer before trusting the image.
You hashed the .zip, vendor checksummed the .bin
Mismatch by mismatch of inputsIf the vendor's checksum is for the extracted image but you hashed the downloaded archive (or vice-versa), the digests won't match even though nothing is corrupt. Hash exactly the file the checksum refers to — unzip first if the published hash is for the .bin inside, then re-hash.
Same-size download but different hash
Corrupt — do not flashA matching file size with a non-matching SHA-256 means a flipped bit or partial corruption a size check can't see. This is exactly the kind of failure that bricks a device mid-flash. Do not write the image; re-download from the official source and re-verify.
Image is larger than your tier's limit
Rejected: too largeThe whole image is read into memory before hashing: Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. A large .img over your cap is rejected with an 'exceeds the … limit for your plan' error. For oversize images, run sha256sum on the file directly — it produces the same value — or use a higher tier / the server-safe runner.
Vendor checksum is uppercase, report is lowercase
ExpectedThe report emits lowercase hex; many firmware vendors and Windows certutil print uppercase. Hex is case-insensitive as a value — lowercase ab12… equals uppercase AB12…. Compare case-insensitively; this is not a mismatch and is safe to flash on.
Only an MD5 or SHA-1 is published
Insecure algorithmMD5 and SHA-1 are collision-broken: an attacker can craft a different image with the same digest. A match still detects accidental corruption from the official source, but it can't prove an untrusted image is safe. Prefer the vendor's SHA-256/SHA-512 if offered; treat an MD5/SHA-1-only match as corruption detection, not adversary-proof verification.
You have a `.asc` / `.sig`, not a checksum
Wrong tool for that fileA .asc/.sig is a PGP signature, not a hash, and can't be matched against the report. Signatures prove who released the image; checksums prove the bytes match a published value. Verify the signature with pgp-message-signer, then match the image's SHA-256 against the signed checksum.
No published checksum exists at all
Can't verify integrityWithout a vendor-published reference value, a hash of your download only describes what you have — it can't confirm it's the correct release. Compute and record the SHA-256 anyway so you can detect later corruption, and pressure the vendor for an official checksum. Don't assume a self-computed hash equals 'verified.'
No file dropped before running
Error: no fileThe tool needs the image file — there's no text-paste mode. Running with an empty dropzone throws 'No file provided.' Drop the firmware file first, then run.
You want to confirm the file is really firmware
Different toolA hash fingerprints exact bytes but won't tell you whether a .bin is a valid image or, say, an HTML error page saved with the wrong extension. To check the real file type from its leading bytes, use magic-byte-validator; to inspect the raw header, use hex-header-inspector.
Frequently asked questions
Why verify firmware before flashing?
Because a corrupted image is one of the few things that can permanently brick a device, and the corruption is invisible until it's too late. A truncated download, a bad mirror, or a flaky USB read can leave you with a file that looks fine and even starts flashing before it fails. Verifying the SHA-256 against the vendor's published checksum first turns a potential brick into a harmless 're-download' — it's the cheapest insurance there is.
Which hash should I match against?
Use whatever the vendor published, preferring SHA-256 (or SHA-512) when offered — those are adversary-resistant. If the only checksum is an MD5 or SHA-1, you can match it for corruption detection, but understand it can't prove an untrusted image is safe, only that your download matches what was posted. Every run computes all four digests, so whichever format the vendor used, the matching line is already on screen.
Does a checksum match mean the image is safe to flash?
It means the bytes are intact — identical to a published value — which rules out a corrupted download. It does not prove the image is authentic: if an attacker controls the source, they can post a malicious image and a matching checksum. For untrusted sources, also verify the vendor's PGP signature over the checksum. From a trusted official source, a SHA-256 match is the standard pre-flash integrity check.
Is my firmware image uploaded anywhere?
No. The image is read into memory in your browser and hashed locally with the Web Crypto API — it never leaves your machine. That's why you can verify an NDA beta firmware, an internal device build, or a custom image without it being uploaded. The only server-side record for signed-in users is a usage counter, never the file.
My download is the right size but the hash doesn't match — is it bad?
Yes, treat it as corrupt and do not flash. A matching size with a different SHA-256 means a bit flipped or part of the file was corrupted during download or storage — exactly the kind of damage a size check can't detect and that can brick a device mid-write. Re-download from the official source and re-verify the hash before attempting the flash.
Do I hash the zip or the extracted image?
Hash whatever the vendor's checksum refers to. If they published the SHA-256 of the .bin inside, extract it first and hash the .bin; if they checksummed the downloadable .zip, hash the zip. A mismatch caused by hashing the wrong layer looks like corruption but isn't — match the input to the published reference.
Does the output match the vendor's sha256sum / certutil?
Yes, byte-for-byte. SHA-1/256/512 are computed with the browser's Web Crypto API and the report prints lowercase hex like sha256sum and shasum. certutil -hashfile on Windows prints uppercase, but it's the same value in a different case — compare case-insensitively. There's no setting that could make your digest differ from the vendor's for the same file.
Can I verify the write landed on the device correctly?
If your flasher supports reading the image back from the chip, yes: fingerprint the readback and compare its SHA-256 to the source image. An identical digest proves every byte was written correctly — stronger evidence than the flasher's own 'success' message. A difference means the write was incomplete or corrupted; re-flash before rebooting the device.
What if the vendor doesn't publish any checksum?
Then there's no reference to verify against, and a self-computed hash only tells you what you downloaded — not whether it's the correct, untampered release. Compute and save the SHA-256 anyway so you can detect any later corruption of your local copy, but don't mistake that for 'verified.' Push the vendor to publish an official checksum (ideally signed).
How big a firmware image can I hash?
Up to your tier's security file-size limit: Free 10 MB, Pro 100 MB, Pro-media 500 MB, Developer 2 GB. The whole image is read into memory before hashing — there's no streaming — so large .img files are bounded by both the cap and browser memory. For an image over the cap, run sha256sum on it locally (the value matches) or use the server-safe runner on a higher tier.
Why is MD5 still offered if it's broken?
Because some older and niche device vendors still publish only an MD5, and you need to be able to match them. For detecting accidental corruption of a download from the official source, an MD5 match is fine. It is not safe against a deliberate attacker, who could craft a different image with the same MD5. Whenever the vendor also offers SHA-256, verify on that instead — it's in the same report.
Can I tell whether the file is actually firmware and not something else?
Not from the hash — a digest only fingerprints exact bytes, it doesn't interpret them. A .bin could secretly be an HTML error page saved with the wrong extension. To confirm the real file type from its leading bytes, use magic-byte-validator; to inspect the raw header directly, use hex-header-inspector. Then verify the hash for integrity.
Privacy first
Every JAD Security operation runs entirely in your browser. Files, passwords, and PGP private keys never leave your device — verified by zero outbound network requests during processing.