UUID vs Hash You're Probably Using the Wrong One Somewhere
Both look like random strings of characters. Both get reached for anytime something needs a unique-looking identifier. They solve genuinely different problems, and mixing them up causes real bugs — not immediately obvious ones, the kind that show up months later.
The actual difference
A UUID is a randomly generated identifier with no relationship to anything else. Generate one twice and you get two completely different values, even with identical input, because there's no input involved — it's just randomness (or, for some UUID versions, a timestamp plus randomness). A standard v4 UUID has 122 bits of actual randomness, which is enough that collisions aren't a realistic practical concern even at massive scale.
A hash is a deterministic fingerprint of specific input. Run the same input through the same hash function twice and you get the identical output, every time. Change one character of the input and the output changes completely and unpredictably — that's the whole point. A hash tells you something about the data it came from; a UUID tells you nothing except that it's unique.
When each one is actually the right tool
| Use case | Use this |
|---|---|
| Primary key for a new database row | UUID |
| Session token / API key | UUID |
| Idempotency key (preventing a duplicate request) | UUID |
| Verifying a downloaded file wasn't corrupted | Hash |
| Detecting duplicate content without comparing full text | Hash |
Cache-busting a filename when content changes (app.a3f8c2.js) |
Hash |
| Storing a password | A hash — but not a plain one, see below |
The password mistake
Storing a raw SHA-256 hash of a password is a common and genuinely dangerous mistake. Plain hash functions are built to be fast, which is exactly the wrong property for password storage — it means an attacker with a leaked hash database can try billions of guesses per second against it. Password storage needs a function specifically designed to be slow and to include a per-user salt — bcrypt, scrypt, or Argon2, not MD5, SHA-1, or SHA-256 used directly. If you're building auth from scratch, this is one of the few places where using a purpose-built library instead of rolling it yourself genuinely matters.
On MD5 specifically
MD5 is cryptographically broken — it's possible to deliberately construct two different inputs that produce the same hash, which makes it unsafe anywhere security depends on that not being possible (verifying a file hasn't been tampered with, for instance). It's still perfectly fine for what it's often actually used for in practice: quick deduplication checks, cache keys, non-adversarial integrity checks where nobody's deliberately trying to fake a match. The distinction is whether anyone has an incentive to break it on purpose.
Generating either
The UUID / GUID Generator produces cryptographically secure random v4 UUIDs, and the Hash Generator computes MD5, SHA-1, SHA-256, and SHA-512 hashes of any text — both running locally, so nothing you're hashing or generating passes through a server.