UUIDs vs Random Strings vs Secrets: Picking an ID
“Just generate a random ID” hides three different jobs that people routinely confuse. A UUID, a short random string and a real secret each answer a different question, and using one where another belongs leads to ugly bugs at best and security holes at worst. The deciding factor is simple: does the value need to be unique, short, or unguessable?
UUIDs: built for uniqueness
A UUID is a 128-bit identifier designed so that anyone, anywhere, can generate one without coordination and still avoid collisions. That is its whole purpose: uniqueness at scale. It is perfect for database primary keys, message IDs and anything where many systems mint identifiers independently. A UUID generator produces them instantly.
The most common form is version 4, which is almost entirely random. A newer version 7 places a timestamp at the front so the values sort by creation time, which databases prefer because it keeps index inserts tidy. Both are unique; v7 is just kinder to storage.
A UUID is unique, not secret. It shows up in URLs and logs and is fine there. Never rely on a UUID being hard to guess. That is not what it is for.
Random strings: short and human-friendly
Sometimes you do not need 128 bits. You need something short that a person can copy, read out or put in a URL. Think share codes, short slugs or invite links. Here a shorter random string from a chosen alphabet is the right fit, trading some uniqueness headroom for brevity. The key questions are how many you will generate and how bad a collision would be; size the length accordingly. For fixed-width random values like tokens in hex, a random hex generator is handy.
Secrets: built to be unguessable
A secret is a different animal. API keys, session tokens and signing keys must be impossible to guess, which means two things: plenty of entropy, and a cryptographically secure random source. A UUID fails here because it is optimised for uniqueness, not unpredictability, and a casual random string may not use a secure generator at all. For anything that grants access, use a secret key generator that draws from a secure source. The same entropy logic behind strong passwords applies here. See our guide to secure passwords.
The decision in one table
| You need | Use | Example |
|---|---|---|
| Uniqueness across systems | UUID (v4 or v7) | Database keys, event IDs |
| Something short and shareable | Random string | Invite codes, short links |
| Something unguessable | Secret | API keys, session tokens |
The mistake to avoid
The classic error is using a UUID as a security token, such as a password-reset link keyed only on a UUID. Because UUIDs are predictable relative to true secrets and often leak through logs, that is a real risk. Keep the roles separate: UUIDs identify, secrets protect.
Frequently asked questions
Is a UUID secret or secure?
No. A UUID is designed to be unique, not unguessable, and it is usually visible in URLs and logs. Treat it as a public identifier. If you need something an attacker cannot guess, generate a dedicated secret instead.
What is the difference between UUID v4 and v7?
UUID v4 is almost entirely random, so values are unordered. UUID v7 puts a timestamp at the front, so values sort roughly by creation time, which is friendlier to databases while staying unique.
Can two UUIDs ever collide?
In theory yes, in practice almost never. A version 4 UUID has 122 random bits, so the chance of generating the same one twice is so small it is safe to ignore for normal applications.
Should I use a UUID as an API key?
No. API keys must be unguessable secrets, and UUIDs are predictable enough that they are the wrong tool. Use a generator that produces a long, cryptographically random secret for keys and tokens.