JPKCom DB

Hash Generator — Tips & Tricks

Security context for the Hash Generator: why MD5/SHA-1 are broken, hashing ≠ encryption ≠ password hashing, and combining with other tools.

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.

The tool deliberately keeps offering MD5 and SHA-1 because both still appear in practice as legacy checksums. Use them with this knowledge — 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 SHA-3 (512)) — longer hash, more security margin, marginally slower.
  • Modern standard with a different construction: SHA-3 (Keccak). Sensible when SHA-3 is explicitly required or you'd rather not build on the SHA-2 family.
  • RIPEMD-160: mainly relevant where it's specifically required (e.g. certain crypto/address formats). Otherwise no reason to prefer it over SHA-256.
  • MD5 / SHA-1: only when the other side dictates it — and only as an integrity, never a security check.

Hashing is neither encryption nor password hashing

Three things are often confused — they are fundamentally different:

  • Hashing (this tool) 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 is its own use case with its own algorithms: BCrypt or Argon2 are deliberately slow and use a salt to slow down brute-force and rainbow tables. Never store passwords as MD5/SHA from this tool — fast hashes are exactly the wrong choice for that. For BCrypt/Argon2 the Generator is the right tool.

In short: if you need it reversible, it's encryption. If it's about storing passwords, you need BCrypt/Argon2. Only for a fingerprint/integrity check are you in the right place here.

Using HMAC correctly

  • HMAC needs a secret. The value is only as strong as the key. Don't type one off the top of your head — use the key button next to the field, which produces a random 64-character passphrase.
  • HMAC ≠ a plain hash with the key appended. HMAC has its own construction, hardened against length-extension attacks. That's exactly why API requests are signed 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.
  • No HMAC for every SHA-3 subtype: in the tool there's an HMAC button only for SHA-3 (512) — the smaller SHA-3 variants don't offer one.

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 — with File Hash, by contrast, the raw file content is hashed, so this problem doesn't arise.
  • Text hash ≠ file hash of the same characters. If you type hello into the Message field, the tool hashes those five characters. A file whose content is hello may differ by an appended line ending. So always compare like with like.
  • Different selection for file vs. text. File Hash computes MD5, SHA-1, SHA-256, SHA-384, SHA-512, SHA-3 (256), SHA-3 (512), RIPEMD-160 — but no SHA-224, SHA-3 (224)/(384), and no HMAC. Those you'll need in the text area.
  • Hex is case-insensitive, but copy cleanly. The output is lowercase hex; a published value in uppercase means the same thing. Compare case-insensitively rather than tripping over the casing.
  • The 100 MB limit. Larger files are rejected. For an even bigger image you'll need a local command-line tool (sha256sum or similar).

Combining with other JPKCom tools

  • Storing passwords? Not here — the Generator does BCrypt/Argon2 (and also provides TOTP codes and secure passwords).
  • 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.