Hash Generator — Tips & Tricks

Back to the overview: Hash Generator · Open the tool live: www.jpkc.com/tools/hash/

The manual explains every algorithm, the examples show the workflows. This page is about the context that should sit above every hash tool: which algorithm for what, what a hash is not, and where the common mistakes lie.

The most important rule: MD5 and SHA-1 are cryptographically broken

MD5 and SHA-1 are considered cryptographically insecure. For both, collisions — two different inputs with the same hash — can be produced with feasible effort. In practice that means:

Do not use them for signatures, certificates, security tokens, or anywhere an attacker would have an interest in slipping in a second input with the same hash.
Still fine as a pure checksum against accidental change — e.g. to spot an unintentionally corrupted download when the vendor only publishes an MD5 value. MD5 still catches random bit errors; it does not stop an attacker.

That's why the tool deliberately files MD5 and SHA-1 under Legacy (not collision-resistant) — together with RIPEMD-160 and CRC-32. Use them with that in mind, and where you have the choice, pick SHA-256.

Which algorithm for what

Integrity / checksums (standard): SHA-256. Widely supported, fast enough, secure. The default recommendation for download verification and file comparison.
Maximum margin: SHA-512 (or SHA3-512, BLAKE2b-512) — a longer hash and a bigger security margin.
SRI for <script> and <link> tags: SHA-384 — the tool automatically prefers it for the SRI line.
Modern standard with a different construction: SHA-3 (SHA3-224 to SHA3-512). Sensible when SHA-3 is explicitly required or you'd rather not build on the SHA-2 family.
Keccak-256: only when Keccak is explicitly required, as in the Ethereum world. Keccak-256 and SHA3-256 are not interchangeable — same length, different values.
BLAKE2 / BLAKE3: modern alternatives outside the SHA families. If a project publishes its checksums with them, you check them the same way via the compare field; in the File tab, BLAKE3 is already preselected.
CRC-32: only for detecting transmission errors or for matching zip, gzip, or PNG checksums. It is not a cryptographic hash and offers no protection against tampering.
RIPEMD-160: mainly relevant where it's specifically required. Otherwise there's no reason to prefer it over SHA-256.
MD5 / SHA-1: only when the other side dictates it — and only as an integrity check, never a security check.

Unknown hash? No need to guess which algorithm produced it: put the input into the Input field and the hash into the compare field — the "Match:" message names the algorithm, because the tool checks against all 20 rows at once.

Hashing is neither encryption nor password hashing

Three things are often confused — they are fundamentally different:

Hashing (Text and File tabs) is a one-way street: the input cannot be recovered from the hash. There is no "decrypt" button, because a hash doesn't encrypt anything — it maps. Good for integrity and fingerprints.
Encryption is reversible (with a key): plaintext in, ciphertext out, and back again with the key. This tool is not for that — use the Cryptor.
Password hashing (Password hashing tab) is a use case of its own, with algorithms of its own: bcrypt, Argon2id, and PBKDF2 are deliberately slow and use a salt to slow down brute force and rainbow tables. Never store passwords as MD5/SHA values from the result table — fast hashes are exactly the wrong choice for that.

In short: if you need it reversible, it's encryption. If it's about storing passwords, use the Password hashing tab. For a fingerprint/integrity check, the Text and File tabs are the right place.

Tuning password hashes correctly

Argon2id is the first choice for new projects — the tool marks it as "recommended". bcrypt remains solid and is supported everywhere; PBKDF2 is mainly for environments that expect it, such as Django.
A measurement in the browser is not a measurement on the server. The info line tells you how long the hash took here and recommends a cost that takes roughly 0.2 to 1 second per hash on your server. Your server may be considerably faster or slower than your laptop — so fine-tune cost, memory, or iterations there.
The Argon2id defaults are the floor. 19 MiB and 2 iterations match the OWASP minimum; PHP itself defaults to 64 MiB and 4 iterations. If your server has the memory, go higher.
bcrypt truncates at 72 bytes. Longer passwords (or passphrases with many non-ASCII characters, which take several bytes each in UTF-8) only count up to byte 72. The tool warns you when that happens.
$2y$ for PHP. When you create a bcrypt hash for a PHP application, leave Prefix on $2y$ (PHP). When verifying, the tool accepts $2a$ , $2b$ , and $2y$ alike.
A new hash on every click is correct. Each run draws a fresh random salt. Two different strings for the same password are not a bug — Verify confirms that both match.
Only these formats can be verified. Verify knows bcrypt, Argon2id in PHC format, and PBKDF2 in Django format (pbkdf2_sha256$…). The tool doesn't verify Argon2i, Argon2d, or scrypt.
Jump straight there: https://www.jpkc.com/tools/hash/#password opens the password tab directly.

Using HMAC correctly

HMAC needs a secret. The value is only as strong as the key. Don't make one up off the top of your head — use the dice button next to the HMAC key field, which generates a random 256-bit key locally.
The key encoding matters. The same string yields completely different HMACs as Text and as Hex, because in one case the characters are the key and in the other the decoded bytes are. If a service hands out its secret as hex or Base64 and computes with the raw bytes internally, switch the encoding accordingly; if it treats the string as text, stay on Text.
HMAC ≠ a plain hash with the key appended. HMAC has its own construction, hardened against length-extension attacks. That's exactly why you sign API requests with HMAC and not with SHA256(key + message).
HMAC-SHA-256 is the default for request signatures and webhooks. Reach for HMAC-MD5/HMAC-SHA-1 only when an endpoint explicitly demands it.
"plain" means: no HMAC. SHAKE128, SHAKE256, BLAKE3, and CRC-32 show the plain hash even with a key and carry a plain badge. Don't mistake these rows for a signature.
Verify a signature instead of eyeballing it. Paste a signature you've received into the compare field; "Match: SHA-256 (HMAC)" confirms it — even if it comes as Base64.

Pitfalls from practice

A hash depends on the exact input. An invisible space, a line ending (\n vs. \r\n), or a different character encoding changes the hash completely. When a text hash "doesn't match," it's almost always one of those invisible differences. The info line below the Input field shows the byte count — if it's off by one, a stray line ending is the usual suspect. Note that the text field always hashes line breaks as \n (LF). To reproduce text with \r\n (CRLF), use Hex bytes or the File tab.
Text hash ≠ file hash of the same characters. If you type hello into the Input field, the tool hashes those five characters. A file containing hello followed by a line break yields a different SHA-256 (5891b5b5…). So always compare like with like.
Select the file algorithms first. In the File tab, the tool only computes the algorithms selected under Algorithms for files. If the comparison says "the algorithm is not selected", switch on the right one and drop the file again.
Case doesn't matter, spaces do. The comparison ignores upper/lower case and treats colons as separators. At the first space, however, it stops reading (that's how sha256sum lines work). If a hash is printed in groups of four separated by spaces, join it before pasting.
Old SHA-3 values from the tool. Earlier versions actually output Keccak under the label "SHA-3". If a SHA3-256 or SHA3-512 value you noted down earlier no longer matches, compare it against the Keccak-256 or Keccak-512 row. Old SHA3-224 and SHA3-384 values have no counterpart today.
History and whitespace. The optional history stores texts without leading and trailing spaces and line breaks. When you restore an entry, the hash can therefore differ from the original if a line ending was part of it — and you may have to switch the input encoding back yourself.
Turning the history off doesn't delete it. The switch only hides the list. To remove stored entries, use Forget.

Combining with other JPKCom tools

Need secure passwords or keys? The Generator produces them (plus TOTP codes and .htpasswd lines). The hash for storing a password is then created here in the Password hashing tab.
Making content confidential? That's encryption — the Cryptor is for that.
Certificates, key pairs, signatures? The PKI complements hashing with the public-key world.

More context: the overview for the big picture, the manual for every algorithm, and the examples for the step-by-step workflows. You can try everything directly in the tool.