UUIDs: What They Are and How to Use Them

UUID stands for Universally Unique Identifier. It's a 128-bit number that looks like this:

`550e8400-e29b-41d4-a716-446655440000`

Let me tell you how I first learned about UUIDs — it was a bug in production. I was using auto-incrementing integers for user IDs, and someone noticed that if you signed up, you could guess the previous user's ID just by subtracting 1.

The key word with UUIDs is "unique." When generated correctly, you can safely assume your UUID is unique across space and time without needing a central authority.

No need to check a database or ask a server — just generate one and use it! That's the magic. You don't need coordination.

UUIDs are sometimes called GUIDs (Globally Unique Identifiers), and the terms are essentially interchangeable in everyday usage. GUID is Microsoft's term, but everyone understands both.

Just how unique are we talking? The number of possible v4 UUIDs is 2^122 — that's about 5.3 undecillion. To put that in perspective: If every person on Earth generated a billion UUIDs per second for a billion years, you'd have a tiny chance of a single collision. For all practical purposes, v4 UUIDs are unique.

Not all UUIDs are the same. There are different versions for different use cases — the version matters! Here's what you need to know about each one:

**Version 4 (Random)** — This is the most common one, and what you want 99% of the time. It's just 122 random bits, with 6 bits used to indicate version and variant. Simple, straightforward, no privacy issues.

**Version 1 (Timestamp + MAC)** — This is the original UUID. It includes the MAC address of the computer generating it. Not great for privacy because anyone with your UUID can figure out what machine generated it and when. Not really needed anymore for most cases.

**Version 7 (Time-Sorted)** — This is the new, hot version that everyone's excited about. It includes a timestamp in the most significant bits, which means UUIDs generated in order will sort in order. Great for database IDs because they keep indexes organized chronologically.

**Versions 3/5 (Name-Based)** — These generate a hash of a name plus a namespace. The same input always gives the same output. Version 3 uses MD5, version 5 uses SHA-1. Useful if you need deterministic UUIDs.

Let me share my recommendation based on years of experience: Use v4 for general purposes, it's the default. Use v7 if you need sortable IDs for database records. Avoid v1 unless you have a specific legacy reason. Use v3/v5 only when you need deterministic IDs.

A quick note on how to tell versions apart: Look at the 13th character. That tells you the version! `xxx-xxx-4xxx` is v4, `xxx-xxx-7xxx` is v7.

UUIDs are everywhere once you start looking for them. Here's where I use them constantly in my work:

**Database IDs** — Instead of auto-incrementing integers that leak information ("how many users do you have?"), use UUIDs. I switched all my personal projects over years ago and never looked back.

**API Resources** — /api/users/550e8400-e29b-41d4-a716-446655440000 is harder to guess than /api/users/123. Enumeration attacks won't work with well-generated UUIDs.

**Temporary Files** — Need to create a temp file without worrying about collisions? UUID filename, done. No race conditions, no overwrites.

**Session Tokens (But Wait)** — Though you should use cryptographically secure tokens specifically designed for auth. But for non-auth session IDs, UUIDs work great.

**Distributed Systems** — Multiple servers can generate IDs without coordination. I've built systems with servers on multiple continents, all generating UUIDs without talking to each other, no collisions.

**Frontend State** — Unique keys for React/Vue/Svelte components without an API call. Great for dynamic forms, list items, anything where you need stable identities on the frontend.

**API Request IDs** — I always send a unique request ID with every API call. It lives in the logs, and when a customer reports a bug, I can trace their exact request instantly.

**Caching Keys** — Need to cache something complex? Generate a UUID for the cache key. Perfect.

**Test Data** — When writing tests, generate UUIDs for test records. Clean and predictable.

UUIDs are random, but that doesn't automatically mean they're secure! There are some important caveats you should understand.

**For v4 UUIDs:** If generated with a CSPRNG (cryptographically secure pseudo-random number generator), they're fine for non-secret uses. In the browser, `crypto.randomUUID()` is safe. In Node.js, `crypto.randomUUID()` is safe. But if someone is using an insecure source of randomness, all bets are off.

**For Security Tokens:** Consider using something longer or specifically designed for secrets. While v4 UUIDs have 122 bits of entropy, I usually prefer 256-bit secrets for auth tokens. Use UUIDs for IDs, use dedicated secret generators for secrets.

**v1 UUIDs:** These can leak the MAC address of the machine that generated them! Don't expose these publicly unless you know what you're doing and have a specific reason to use v1.

**Don't expose sequential UUIDs:** Even though v4 and v7 aren't sequential, be careful about exposing any IDs that might let attackers guess the volume of your data. v7 is predictable in time — that's its strength for sorting, but something to be aware of.

**Never use UUIDs for passwords** or as the only security mechanism. They're for identification, not for secrets. A UUID in a URL is fine (for public resources), but a UUID for authentication isn't good enough.

One more thing: If you're using UUIDs in URLs, remember that they're case-insensitive. But when storing them in databases, store them consistently — either all lowercase or all uppercase, but not mixed. Our UUID Generator outputs lowercase, which is the most common.

Let's look at how to actually generate and work with UUIDs in code — these are snippets I use weekly.

**In the browser (modern):**

// Generate a UUID (v4)
const uuid = crypto.randomUUID();
console.log(uuid); // '550e8400-e29b-41d4-a716-446655440000'

**Node.js:**

import crypto from 'crypto';
const uuid = crypto.randomUUID();
console.log(uuid);

**Python:**

import uuid
# Generate a v4 UUID
id = uuid.uuid4()
print(id)

PostgreSQL has UUID support built-in: `CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE TABLE users (id UUID PRIMARY KEY DEFAULT uuid_generate_v4());`

MySQL too has UUID functions, and databases like MongoDB use UUID-like IDs by default.

**Storing UUIDs in databases:** There's debate about storing them as strings vs binary. For most projects, string is fine and much easier to debug. If you're optimizing for extreme performance, binary is slightly smaller and faster to index, but the complexity isn't worth it for most apps.

One last tip: Use our UUID Generator when you need quick UUIDs for testing, debugging, configuration files, or anything where you don't want to write code!