| # | File | Size | Algo | Salt | Pos | Hash | Copy |
|---|---|---|---|---|---|---|---|
| {{ r.idx }} | {{ r.name }} | {{ r.size_human }} | {{ r.hash_type }} | {{ r.salt ? 'Yes' : 'No' }} | {{ r.salt ? (r.salt_position === 'prefix' ? 'Prefix' : 'Suffix') : '—' }} | {{ r.digest }} | |
| No history yet. | |||||||
A file hash is a short fingerprint calculated from the exact bytes inside a file. People use it when they need confidence that a download, backup, archive, or disk image is still the same object they expected, because even a one-byte change produces a different digest.
This page calculates that fingerprint from a local file in the browser, then lets you compare runs across several hash families. It is most useful when you already have a checksum from a trusted source and need to confirm whether your copy is byte-for-byte identical.
The tool covers both current and legacy workflows. You can generate MD5, SHA-1, SHA-2, SHA-3, and RIPEMD-160 digests, add an optional text salt before or after the file bytes, and switch the displayed hexadecimal text to uppercase or lowercase without changing the underlying value.
A matching digest is a strong integrity signal, but it answers a narrow question. It says the compared bytes match. It does not prove who created the file, whether the download channel was trustworthy, or whether the file is safe to open or run.
That boundary matters most when people mix verification and trust. Checksums help detect corruption, incomplete transfers, accidental edits, and many forms of tampering, but authenticity still depends on where the file came from and whether there is a signature or another trusted release process behind it.
The safest everyday workflow is simple: choose the same algorithm named by the source you trust, leave the salt blank, hash the file, and compare the resulting digest character for character with the published checksum. If the reference says SHA-256, a digest from MD5, SHA-1, or any SHA-3 variant is not a valid substitute even when the file is correct.
This tool is especially practical for operating-system images, software installers, firmware files, compressed backups, and handoffs between teams. In those cases the question is usually narrow and concrete: did the file I received remain unchanged? The answer comes from exact digest equality under the same settings, not from the digest looking long, modern, or visually similar.
The optional salt exists for workflows where you deliberately want the digest to depend on extra text as well as the file itself. That can be useful for internal tagging or controlled comparisons, but it also means the result is no longer the plain digest of the file. A salted output should never be compared with a vendor checksum unless that same salt and position were part of the agreed method.
Casing is easier to interpret. Uppercase and lowercase hexadecimal output represent the same digest value. If every character matches apart from letter case, the digest still matches. By contrast, a change in algorithm, salt text, or salt position produces a digest for different input data and should be treated as a different calculation.
The extra tabs are session summaries, not stronger proof. They help you review what happened across multiple runs, spot which algorithms you used, and see whether a session mixed salted and unsalted results. They do not change the trust level of any single checksum comparison.
The hashing workflow runs on the file you choose from local storage. The script reads the file incrementally in 2 MiB chunks, feeds those bytes into the selected hash function, then finalizes a hexadecimal digest when the last chunk is processed. That chunked approach matters for larger files because it avoids needing one large in-memory copy before hashing can begin.
Salting is implemented by encoding the entered text as UTF-8 and concatenating it either before or after the file bytes. Prefix and suffix mode therefore create different byte streams, and different byte streams produce different digests. The random-salt button generates a 16-byte value represented as hexadecimal text, which is convenient for ad hoc testing but still changes the comparison target on purpose.
Every completed run becomes a history row with the file name, size, algorithm, salt status, salt position, and digest. If you load one file and then change the algorithm, casing, or salt settings, the page recalculates and records another row. History is kept in page memory for the current session and capped at 500 rows, with older rows dropped first once the limit is reached.
The result surfaces are built around that session history. The main digest panel shows the latest output, the history table records each run, the algorithm chart summarizes how often each hash family was used, the salt-and-casing chart shows how many runs were salted or unsalted, and the JSON tab packages the latest run together with the full session log.
| Algorithm family | Variant in this tool | Digest bits | Hex characters |
|---|---|---|---|
| MD5 | MD5 | 128 | 32 |
| SHA-1 | SHA-1 | 160 | 40 |
| SHA-2 | SHA-224 | 224 | 56 |
| SHA-2 | SHA-256 | 256 | 64 |
| SHA-2 | SHA-384 | 384 | 96 |
| SHA-2 | SHA-512 | 512 | 128 |
| SHA-3 | SHA3-224 | 224 | 56 |
| SHA-3 | SHA3-256 | 256 | 64 |
| SHA-3 | SHA3-384 | 384 | 96 |
| SHA-3 | SHA3-512 | 512 | 128 |
| RIPEMD | RIPEMD-160 | 160 | 40 |
A correct comparison requires the same file bytes and the same calculation settings. In practical terms that means the algorithm must match, the salt must either be absent in both places or identical in both places, and the salt position must match as well. Letter case does not affect the digest meaning, but almost every other setting does.
Older algorithms remain in the list for compatibility because many published checksum manifests still use them. That does not make all algorithms equally suitable for security-sensitive decisions. MD5 and SHA-1 can still tell you whether two ordinary byte streams match in day-to-day integrity checks, but they are no longer the preferred choice where collision resistance against deliberate attack is a requirement.
This slug ships without a server-side helper, and the hashing path shown in the package reads the selected file directly in the browser. The file content is processed locally, the session history lives in memory until the page is closed or reloaded, and the available exports are generated from that local session state rather than from a remote hash job.
If the result does not match, check the algorithm first, then confirm that no salt was applied by mistake, and only after that investigate whether the file itself changed.
The latest digest is the main answer. When it matches the trusted checksum exactly, the compared byte streams are identical. When it does not, the cause is almost always one of four things: the file bytes differ, the wrong algorithm was selected, a salt was added or positioned differently, or the reference text itself is wrong.
| Observed outcome | What it means here | What to check next |
|---|---|---|
| Digest matches apart from letter case | The value still matches. | No further action is needed unless your workflow requires a specific display style. |
| Digest length differs from the reference | You are almost certainly using a different algorithm family. | Switch to the exact algorithm named by the source. |
| Digest changes when you add or move a salt | The tool is hashing different input data. | Remove the salt for ordinary checksum verification or match the shared salting rule exactly. |
| Repeated mismatch with the same settings | The file or the reference checksum differs. | Re-download the file, re-check the published checksum, or confirm the source channel. |
The charts and exports are useful for auditability within a session, but the trust decision still comes from the digest comparison itself. A pie chart or JSON record cannot rescue a mismatch caused by wrong settings or a changed file.
Verifying a large installer. A software vendor publishes a SHA-256 checksum beside a download. You choose the installer file, keep the tool on SHA-256, leave the salt blank, and compare the 64-character digest with the published value. A full match means your copy is byte-identical to the vendor reference.
Checking an internal artifact with a private tag. Your team wants a digest that depends on both the file and a release label such as qa-2026-03. You enter that text as a salt, keep the agreed prefix or suffix rule, and share the resulting digest only within that workflow. The changed output is expected because the hashed byte stream is no longer the bare file.
Troubleshooting a mismatch. You receive an MD5 checksum from a legacy system but forget to switch away from SHA-512. The result looks valid and polished, but it cannot match because it is a different algorithm with a different digest length. Once you switch to MD5 and remove any leftover salt, the comparison becomes meaningful again.
The shipped package reads the selected file in the browser and hashes it locally. There is no bundled server-side helper for the hashing step in this slug.
Yes. Keeping the same file selected and changing the algorithm recalculates the digest and adds another history row, which is useful when you need to match different checksum lists for the same file.
Because the salt becomes part of the hashed byte stream. Even with the same file, a different salt or a different salt position produces a different digest.
No. A matching digest confirms byte equality with the reference you used. It does not prove who created the file or that the source channel was authentic.
The page keeps up to 500 history rows for the current session. When the limit is exceeded, the oldest rows are removed first.