A vendor publishes an installer with a SHA-256 next to the download link. A client emails you a config file and says “here is exactly what is in production.” A backup tarball lands on a remote host and you want to prove the bytes that arrived match the bytes that left. All three are the same question: are these two things — the thing I have and the thing somebody else has — actually identical, byte for byte? PortJar’s Hash Generator answers it without needing to install anything.
What the tool does
Hash Generator takes any text input and returns four hashes in one pass: MD5, SHA-1, SHA-256, and SHA-512. It runs entirely client-side — the input never leaves your browser tab — which means you can hash secrets, internal config values, or sensitive payloads without worrying about server-side logging.
The four algorithms are not interchangeable. MD5 and SHA-1 are fast and small, but cryptographically broken; collisions can be deliberately engineered. They are still fine for non-adversarial checksums — confirming a download did not get corrupted in transit, comparing two versions of a config file, indexing a cache. SHA-256 and SHA-512 are slower, larger, and currently considered collision-resistant; use them anywhere an attacker might benefit from forging a match (signing, content addressing, deduplication where two distinct inputs producing the same hash would cause damage).
How to use it
Open portjar.com/tools/hash-generator, paste the text, hit Run, and all four hashes appear together. The example chips load hello world and The quick brown fox if you need a quick sanity check that the algorithm output matches what a textbook or a shell command would produce. For comparing to a vendor’s published hash, copy the relevant algorithm’s output and diff it against what they published — character by character, not eyeballed.
For hashing actual files rather than text, the tool is the wrong shape — paste the text representation of a value, not a binary file. For files, run sha256sum (Linux), shasum -a 256 (macOS), or Get-FileHash (PowerShell) locally; the algorithms are identical, only the input source differs.
When you’d reach for it
- Verifying a vendor-supplied installer or image against the SHA-256 they published, before running it on a production host. A mismatch is either a corrupt download or, in the worst case, a man-in-the-middle replacement; either way you do not run it.
- Confirming two config files claimed to be identical actually are. Paste each file’s contents in turn, compare the SHA-256. Two matching hashes proves byte equality without having to diff thousands of lines.
- Generating a stable identifier for a webhook payload or notification key, so that retries with the same body collapse to a single entry rather than firing repeatedly. SHA-256 of the payload is the conventional choice.
- Producing a cache key for an internal lookup table where the input is large but you only need a short fixed-length identifier — for example, hashing a normalized SQL query to use as a cache lookup.
- Checking whether a config or credential changed during a deployment. Hash the value before the change and after. If the hashes match, the change did not land; if they differ, the change did land — even when the new value is supposed to look identical at a glance, like a re-encoded PEM that gained a trailing newline.
What to make of the output
A matching hash to a known-good reference is the answer you want — the two inputs are byte-for-byte identical, end of conversation.
A mismatching hash is more interesting than it looks. Before assuming the file is wrong, check for the three common sources of false-positive mismatches: trailing newlines (paste the same content into the tool twice with and without a final newline and you get two different hashes); line endings (\n vs \r\n change every line and therefore every hash); and character encoding (UTF-8 vs UTF-16 vs Windows-1252). For text-based config files, normalizing line endings to \n and stripping or adding a trailing newline often resolves the mismatch instantly.
If all four hashes differ between two inputs you believed identical, the inputs really are different — there is no algorithm-level explanation for “the SHA-256 differs but the MD5 matches.” A mismatch on one algorithm and a match on another means you compared different things in the two cases, not that one algorithm “disagrees” with another.
For non-adversarial integrity (download corruption, accidental drift), MD5 is still fine — a chance collision on a non-malicious 1 GB file remains astronomically unlikely. For anything an attacker might exploit, only SHA-256 or SHA-512 belong in the conversation. If a vendor still publishes only MD5 alongside a sensitive download, that is itself a finding worth flagging.
Stack Harbor uses hash verification as a standard step when copying images, backups, and certificate bundles between environments we run as part of environment management as a service.