The difference is the timestamp
UUID v4 is random; UUID v7 begins with a millisecond timestamp. Both occupy 128 bits and use the familiar 36-character form with hyphens. Use the UUID generator to select either version.
| Property | v4 | v7 |
|---|---|---|
| Time field | None | 48-bit Unix milliseconds |
| Randomness | 122 bits | Up to 74 bits; implementations may use counters |
| Time ordering | No | By timestamp; see limits below |
| Creation time visible | No embedded timestamp | Yes |
These layouts are specified in RFC 9562 §5.4 and §5.7.
When to choose v4 or v7
Choose v4 for random public IDs when you do not want an embedded creation time. Consider v7 for records that benefit from ordering by creation time, after checking your database, ORM and library support. Measure database performance with your own workload instead of assuming a universal speedup.
Time-ordered does not mean strictly sequential
This site's v7 implementation writes the timestamp followed by 74 random bits. IDs created within the same millisecond are not guaranteed to sort in generation order. Clock changes and distributed hosts also affect ordering. A UUID is not a transaction sequence number.
Keep identifiers separate from access tokens
Do not use knowledge of an ID as an authorization check. For reset links or bearer credentials, use dedicated random bytes, an expiry and server-side validation. Our API key generator and hex generator create random secret material.
What about ULID?
ULID uses a timestamp too, with a 26-character base32 representation. Keep an existing ID scheme unless a migration has a clear benefit. See the ULID specification for its encoding and optional monotonic behavior.