How to per-file checksum generator vs sha256sum / openssl / get-filehash
- Step 1Decide on privacy needs — Both run locally, so both are private. The difference: the browser path needs no install and no admin rights, which matters on managed/corporate machines where you can't add
p7ziporcoreutils. - Step 2Decide on volume — For one-off manifests of an archive under your tier cap (50 MB free, up to 2 GB paid), the browser tool is faster end-to-end because there's no extract step. For thousands of archives or multi-GB inputs, script the CLI.
- Step 3Pick the algorithm to match — Set the Algorithm dropdown to SHA-256, SHA-1, or MD5 to match whatever the other side uses.
sha256sum↔ SHA-256,sha1sum↔ SHA-1,md5sum↔ MD5, oropenssl dgst -sha256for any of them. - Step 4Generate in the browser — Drop the archive, click Process, download the
.sha256sums. It's already in coreutils format — no reformatting needed. - Step 5Verify with the CLI — On the server, extract the archive into the same relative paths and run
sha256sum -c <archive>.sha256sums. Every entry reportsOKorFAILED. - Step 6Or generate on the CLI and audit in the browser — Run the CLI manifest, then import its CSV cousin (the browser tool's CSV) into a spreadsheet to sort, filter and diff. Use Archive Diff to compare two archives directly.
Browser tool vs command-line utilities
All comparisons are for hashing the files INSIDE an archive. The browser tool extracts and hashes in one step; CLI tools require a separate extraction first.
| Capability | JAD Checksum Generator (browser) | sha256sum / md5sum (coreutils) | openssl dgst / Get-FileHash |
|---|---|---|---|
| Install required | None (web page) | Usually preinstalled on Linux/macOS | openssl preinstalled; Get-FileHash built into PowerShell |
| Reads inside an archive | Yes — extracts then hashes each entry | No — you must extract first | No — extract first |
| Formats handled | ZIP, TAR, GZ, 7z, RAR, BZ2, XZ, ISO, encrypted ZIP | Any file once extracted | Any file once extracted |
| Encrypted archives | Encrypted ZIP via password field (not 7z/RAR) | Needs unzip -P / 7z x -p first | Needs separate extraction |
| Output | CSV + GNU .sha256sums (two files) | GNU <hash> <name> lines | openssl: SHA256(file)= …; Get-FileHash: object |
| Size ceiling | 50 MB free → 2 GB paid, per archive | None (disk/RAM bound) | None |
| Scriptable / CI | No API yet — UI only | Yes | Yes |
Algorithm to CLI mapping
Pick the dropdown value that matches the CLI on the other side. Hash values are identical across engines for the same input bytes.
| Dropdown value | coreutils | openssl | PowerShell |
|---|---|---|---|
| SHA-256 | sha256sum | openssl dgst -sha256 | Get-FileHash -Algorithm SHA256 |
| SHA-1 | sha1sum | openssl dgst -sha1 | Get-FileHash -Algorithm SHA1 |
| MD5 | md5sum | openssl dgst -md5 | Get-FileHash -Algorithm MD5 |
Cookbook
Browser action on the left, the CLI equivalent on the right. Use them interchangeably — the manifest formats line up.
Per-file manifest of a ZIP
What the browser tool does in one drop vs the two-step CLI pipeline.
Browser: drop release.zip → SHA-256 → Process → download release.sha256sums
CLI equivalent:
$ mkdir t && cd t && unzip ../release.zip
$ find . -type f -exec sha256sum {} + > ../release.sha256sumsVerify a browser-generated manifest on a server
The .sha256sums file is plain coreutils format, so the standard check just works.
$ unzip release.zip $ sha256sum -c release.sha256sums ./bin/app: OK ./README.md: OK
Match a vendor MD5 list
Switch the dropdown to MD5; the CLI cousin is md5sum.
Browser: Algorithm = MD5 → Process
CLI equivalent:
$ find . -type f -exec md5sum {} +Hash an encrypted ZIP
The browser tool decrypts with a password field; the CLI needs to extract with the password first.
Browser: drop secure.zip → enter password → Process
CLI equivalent:
$ 7z x -pPASSWORD secure.zip -o out
$ cd out && find . -type f -exec sha256sum {} +Windows PowerShell equivalent
Get-FileHash over an extracted tree, formatted like the browser CSV.
Browser: drop archive.zip → SHA-256 → download archive-sha256.csv PowerShell equivalent: Get-ChildItem -Recurse -File | Get-FileHash -Algorithm SHA256 | Select-Object Path, Hash
Edge cases and what actually happens
Two spaces vs one in the sums file
By designThe browser tool writes the GNU <hash> <name> format with two spaces, exactly what sha256sum -c expects. A single space (the --tag/BSD style) won't verify the same way — keep the two-space form.
Paths differ between generation and verification
ExpectedThe names in the manifest are the archive's internal entry paths. To verify with sha256sum -c, extract the archive so files sit at those same relative paths, or cd into the extraction root first.
Multi-GB archive
Use CLIThe browser caps archives at 2 GB on paid tiers and is memory-bound. For larger inputs, extract and hash with sha256sum on a machine with adequate RAM/disk.
CI/CD pipeline needs automation
Use CLIThere is no API for this tool yet. In a pipeline, run sha256sum directly. Use the browser tool for ad-hoc, interactive, or untrusted-input cases.
openssl output looks different
Expectedopenssl dgst -sha256 file prints SHA256(file)= <hash>, not the coreutils <hash> <name> order. The hash value is identical; only the line format differs. The browser tool emits coreutils format for direct -c verification.
Encrypted 7z/RAR
Use CLIThe browser tool can't supply passwords to libarchive (7z/RAR). Decrypt with 7z x -p / unrar locally and hash the extracted files, or re-archive as an encrypted ZIP via Encrypted ZIP Creator.
Get-FileHash uppercase hashes
CosmeticPowerShell returns uppercase hex; coreutils and this tool use lowercase. They're the same value — lower-case the PowerShell output (.ToLower()) before a string comparison.
Comparing two archives, not one
Wrong toolIf you want to know what changed between two archives, generate per-file hashes of both and diff — or skip straight to Archive Diff, which compares two ZIPs by name and CRC32 directly.
Frequently asked questions
Are the hash values identical to sha256sum?
Yes. SHA-256 of a given byte stream is the same everywhere. The only differences between this tool and the CLI are convenience, formats read, and the surrounding line format — not the hash itself.
Can I verify a browser-made manifest with sha256sum -c?
Yes. The .sha256sums file uses GNU coreutils format (<hash> <name>, two spaces), so sha256sum -c <file>.sha256sums works after you extract the archive to matching paths.
When should I prefer the browser tool?
One-off manifests, machines where you can't install software, untrusted input you don't want to extract to disk via shell, or when the archive is a 7z/RAR/encrypted-ZIP you'd otherwise need extra utilities for.
When should I prefer the CLI?
Multi-GB archives, thousands of files, CI/CD automation, or any workflow already running on a server where coreutils/openssl are present.
Does the browser tool read 7z and RAR like 7z does?
It reads (extracts) them via libarchive WASM, then hashes each entry. It does not write 7z/RAR, and it can't supply passwords to them — those are read-only and unencrypted-only via libarchive.
How does openssl dgst compare?
openssl dgst -sha256 produces the same hash but a different line format (SHA256(file)= …). The browser tool's output is coreutils-style, which -c verification understands directly.
Is the CSV useful for CLI users too?
Yes — the name,size,<algo> CSV is easy to sort, filter, or diff in a spreadsheet or with awk/csvkit, complementing the .sha256sums verification file.
Can I hash files larger than 2 GB?
Not in the browser — 2 GB is the paid-tier ceiling and memory is the real constraint. Use sha256sum on the extracted file for anything bigger.
Does Get-FileHash give the same result?
Yes, byte-for-byte, just in uppercase hex. Lower-case it before comparing strings with the lowercase output this tool and coreutils produce.
Is there any JAD-specific wrapper around the output?
No. The CSV is plain RFC 4180 CSV and the sums file is plain coreutils format. Nothing is proprietary — both interoperate with standard tools.
Does the browser tool need internet after loading?
No. Once the page and its WASM engines are loaded, hashing runs offline. The CLI is offline by definition.
Which is faster?
For small-to-medium archives the browser tool wins end-to-end because there's no separate extract step. For very large inputs or batches, the CLI wins on raw throughput and no size cap.
Privacy first
Every JAD Archive tool runs entirely in your browser using fflate, @zip.js/zip.js, and the libarchive WASM bridge. Your archives never leave your device — verified by zero outbound network requests during processing.