| # | Time | File | Size | Algo | Salt | Pos | Case | Hash | Copy |
|---|---|---|---|---|---|---|---|---|---|
| {{ r.idx }} | {{ r.local }} | {{ r.name }} | {{ r.size_human }} | {{ r.hash_type }} | {{ r.salt ? 'Yes' : 'No' }} | {{ r.salt_position }} | {{ r.uppercase ? 'UP' : 'low' }} | {{ r.digest }} | |
| No history yet. | |||||||||
File checksums are compact fingerprints that identify a file by its exact bytes and help you confirm that nothing changed. They give you a simple way to spot unwanted differences in downloads and archives with clear yes or no comparisons.
Hashes convert any file into a fixed length digest so identical files produce the same output and any alteration shows up immediately. A common use is file checksum verification for downloads where you compare your result to a value published by the author.
Optional salt lets you explore alternate fingerprints for research or tagging while ordinary integrity checks usually rely on unsalted digests. You can place the salt before the data or after the data to match either convention.
For reliable comparisons keep inputs consistent and copy the entire hex string without extra spaces. Large files compute in steady chunks so let the process finish and then copy or save the result.
A matching checksum confirms that bytes match the expected file and it does not prove who created it or whether the file is safe to run. Use known good sources and signatures when authenticity matters.
The computation maps a file’s byte sequence f and an optional UTF‑8 text salt s to a fixed‑length hexadecimal digest D. The digest is produced by a selected hash function H chosen from MD5, SHA‑1, SHA‑2 (224, 256, 384, 512), SHA‑3 (224, 256, 384, 512), or RIPEMD‑160.
The result encodes the digest as hexadecimal; letter casing is a display choice only. Matching digests indicate byte‑for‑byte equality, while any difference implies the compared files are not identical. Unsalted digests are intended for comparison with published checksums; adding a salt intentionally changes the output.
To remain responsive on large inputs, the hashing engine reads the file in 2 MiB chunks and updates the digest incrementally. Size readouts use IEC units (KiB, MiB, GiB) with two decimal places, and event times are recorded using the device’s local time format.
| Symbol | Meaning | Unit/Datatype | Source |
|---|---|---|---|
| f | File byte sequence | bytes | Input |
| s | Salt encoded as UTF‑8 | bytes | Input |
| H | Selected hash function | algorithm | Parameter |
| D | Hexadecimal digest | string | Derived |
| pos | Salt position rule | prefix/suffix | Parameter |
| Algorithm | Digest bits | Hex chars |
|---|---|---|
| MD5 | 128 | 32 |
| SHA‑1 | 160 | 40 |
| SHA‑2‑224 | 224 | 56 |
| SHA‑2‑256 | 256 | 64 |
| SHA‑2‑384 | 384 | 96 |
| SHA‑2‑512 | 512 | 128 |
| SHA‑3‑224 | 224 | 56 |
| SHA‑3‑256 | 256 | 64 |
| SHA‑3‑384 | 384 | 96 |
| SHA‑3‑512 | 512 | 128 |
| RIPEMD‑160 | 160 | 40 |
| Field | Type | Min | Max | Step/Pattern | Error Text | Placeholder |
|---|---|---|---|---|---|---|
| File | File | 0 bytes | — | Any file type | — | — |
| Salt | Text | 0 | — | UTF‑8 text | — | leave blank for none |
| Salt position | Enum | — | — | prefix | suffix | — | — |
| Hash type | Enum | — | — | MD5, SHA‑1, SHA‑2, SHA‑3, RIPEMD‑160 | — | — |
| Output casing | Boolean | — | — | lowercase | UPPERCASE | — | — |
| History length | Integer | 0 | 500 | oldest entries drop first | — | — |
| Input | Accepted Families | Output | Encoding/Precision | Rounding |
|---|---|---|---|---|
| File | Any local file | Digest | Hex string, optional uppercase | Sizes to two decimals (IEC) |
| Salt | UTF‑8 text | Salted digest | Hex string, optional uppercase | Not applicable |
Families correspond to well‑known standards such as the Secure Hash Standard series, the SHA‑3 specification, and international hash function norms for message digests.
No data is transmitted or stored server‑side. Clipboard operations and downloads occur on the device under your control.
File checksums confirm integrity by comparing a computed digest to a known reference.
Example: Choose SHA‑2‑256, leave salt blank, and hash a downloaded installer; compare the 64‑character hex to the value published by the author.
No. Files are processed in the browser and the history lives only in memory unless you copy or download it.
Clipboard and downloads are explicit user actions.For a given file and settings the result is exact and deterministic. Any mismatch against a reference means the bytes differ.
Digests are hexadecimal strings. Sizes use KiB, MiB, and GiB with two decimals. Times follow your device’s locale.
Yes, once loaded it operates without a network connection. All processing is on the device.
No. It changes only how letters are shown. The underlying digest value is the same.
Check that the same algorithm was used and that salt is blank when comparing to a published checksum. Ensure no extra spaces were copied.
Compute the digest here with the specified algorithm, then compare it to the value posted by the publisher. Values must match exactly.
There is no borderline in hashing. Digests either match or they do not; any difference means different bytes.
Usage does not imply a license for third‑party content. Review the terms for any files you verify.
Tip Keep a plain text audit file that lists digest, two spaces, and filename for each item.
Tip When verifying archives, hash the final downloaded file rather than extracted contents.
Tip Prefer unsalted digests for public comparison; use salts only for internal workflows.
Tip Record the algorithm and letter casing alongside the digest for clarity.
Tip Recompute after any file move or edit to avoid stale values.
Tip If you must retype a digest, group by four characters to reduce mistakes.