UUID, Hashing, and JWT: Identity Tokens Explained

How does a database assign an ID that no other database on Earth will ever duplicate? How can a server verify your login without storing your session? These questions lead to three foundational concepts in software: UUIDs, hashing, and JWTs. Each solves a different identity problem, and understanding when to reach for each one is a core skill in backend development.

UUIDs: universally unique identifiers

A UUID is a 128-bit identifier designed to be unique across space and time without a central authority. The standard format is 32 hex digits in five groups: 550e8400-e29b-41d4-a716-446655440000. With 2¹²² possible values for a random UUID, the chance of collision is astronomically small.

v4 vs v7

UUID v4 is purely random — 122 bits of randomness from a cryptographic source. It's the most widely used version today. The downside is that v4 UUIDs are unsortable — you cannot determine which was created first by looking at the values.

UUID v7 (standardised in RFC 9562, 2024) embeds a Unix timestamp in the first 48 bits, followed by random bits. This means v7 UUIDs are timestamp-sortable — database indexes love them because new rows are always appended, never inserted in the middle of a B-tree.

Hashing: one-way fingerprints

A hash function takes input of any size and produces a fixed-size output called a digest. Three properties make hashing useful:

• Deterministic — the same input always produces the same output
• One-way — you cannot reconstruct the input from the digest
• Avalanche effect — changing a single bit in the input flips roughly half the bits in the output

Broken vs secure algorithms

MD5 and SHA-1 are collision-vulnerable — researchers have demonstrated two different inputs that produce the same hash. For password storage, use purpose-built functions like bcrypt or Argon2, which add salt and deliberate slowness to resist brute force.

JWTs: stateless authentication tokens

A JSON Web Token is a compact, URL-safe string that carries claims about a user. It has three parts separated by dots: header.payload.signature. Each part is Base64url-encoded JSON.

// Header
{
  "alg": "HS256",
  "typ": "JWT"
}

// Payload
{
  "sub": "1234567890",
  "name": "Jane Doe",
  "iat": 1516239022,
  "exp": 1516242622
}

// Signature
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)

Signed, not encrypted

A critical misconception: JWTs are signed but not encrypted by default. Anyone can decode the header and payload — the signature only proves the token wasn't tampered with. Never put sensitive data (passwords, credit card numbers) in a JWT payload unless you also encrypt it (JWE).

When to use each

• UUIDs — when you need a unique identifier without coordination (database primary keys, distributed systems, file names)
• Hashing — when you need to verify integrity or store secrets (password storage, file checksums, data deduplication)
• JWTs — when you need stateless authentication between services (API auth, single sign-on, short-lived access tokens)

UUIDs identify things. Hashes verify things. JWTs authenticate things. Each answers a different question — and the strongest systems use all three together.