UUID
v4 and v7 identifiers, single or in bulk
A UUID is a 128-bit identifier written as 32 hexadecimal digits in five hyphen-separated groups. The point is that it can be generated anywhere, by anyone, without asking a central authority, and still be unique — which is what makes it useful for database keys created on a client, for correlation IDs across services, and for anything that has to be named before it reaches a server.
Version 4 fills almost all of those bits with randomness: 122 random bits, with the remaining six fixed to mark the version and variant. Version 7, standardised in RFC 9562, puts a 48-bit Unix millisecond timestamp at the front and randomness after it, so identifiers sort chronologically. That single property makes v7 dramatically friendlier to database indexes than v4.
How to use it
- Choose a versionVersion 4 for pure randomness, version 7 when you want identifiers that sort by creation time. Both are 128 bits and both are written in the same format.
- Set how many you needGenerate one, or a few thousand for seeding a test database. Values come from crypto.getRandomValues, the browser’s cryptographically secure source, not from Math.random.
- Copy them outCopy a single value or the whole list at once. Nothing is generated on a server, so no identifier you see here has ever existed anywhere else.
Frequently asked questions
What is the difference between UUID v4 and v7?
v4 is 122 bits of randomness with no structure, so two UUIDs created a second apart are unrelated and unordered. v7 begins with a millisecond timestamp, so identifiers generated later sort after earlier ones as plain strings. If you are using UUIDs as a primary key, v7 is almost always the better choice.
Can two UUIDs ever collide?
In principle yes, in practice no. With 122 random bits you would need to generate roughly 2.7 quintillion v4 UUIDs before reaching a one-in-a-billion chance of a single collision. The realistic risk is not the mathematics but a weak random source — which is why generating them with Math.random rather than a cryptographic API is a genuine bug.
Why are UUID primary keys said to hurt database performance?
Because random v4 values arrive in no particular order, every insert lands at a random point in the index, fragmenting B-tree pages and destroying locality. v7 fixes exactly this: because the timestamp leads, new rows append to the end of the index the way an auto-increment integer does, while keeping the client-side generation that made UUIDs attractive.
Is a UUID the same thing as a GUID?
Yes. GUID is Microsoft’s name for the same 128-bit identifier, and the two terms are interchangeable in practice. The only thing to watch is formatting: some Microsoft tooling wraps the value in braces and some serialisations of GUIDs byte-swap the first three groups.
Does a version 7 UUID leak when something was created?
Yes, deliberately — the first 48 bits are a Unix timestamp in milliseconds and anyone holding the identifier can read it. That is a feature for sortability and a consideration for privacy. If the creation time of a record is sensitive, use v4.
Are these UUIDs safe to use as security tokens?
A v4 UUID from a cryptographic source has 122 bits of entropy, which is ample for a session or invite token. A v7 UUID is not, because half of it is a predictable timestamp. When in doubt, generate a dedicated random secret rather than reusing an identifier that may be logged or exposed in a URL.