What is a UUID?
A UUID is a 128-bit identifier written as 32 hexadecimal characters in a8-4-4-4-12pattern. The point of the format is that any machine can mint one without asking a central authority and still be confident nobody else will produce the same value. That is why UUIDs show up wherever an auto-incrementing integer would be awkward: distributed systems, offline-first clients, and anywhere a client needs an ID before it talks to the server.
Two of the characters are not random. The first digit of the third group is the version, and the first digit of the fourth group encodes the variant. That is how the validator above can tell you what kind of UUID you pasted without any lookup.
v4 vs v7: which one you want
Version 4 is 122 random bits and nothing else. It reveals no information about when or where it was created, which makes it the right pick for public-facing tokens, share links, and anything a user might see.
Version 7 puts a Unix millisecond timestamp in the leading 48 bits and randomness in the rest, so the values sort chronologically as plain strings. This matters more than it sounds: random v4 keys scatter inserts across a B-tree index, fragmenting pages and pushing write amplification up as the table grows. Sequential v7 keys append to the end of the index instead, which is why Postgres and MySQL shops have been switching to it. The tradeoff is that anyone holding the ID can read its creation time.
The simple rule: v7 for database primary keys, v4 for anything exposed publicly.
Generating them in code
Modern browsers and Node both ship a native v4 generator, so you rarely need a library for it:
// Browser and Node 19+
const id = crypto.randomUUID();
// Node, any version
import { randomUUID } from "node:crypto";
// Python
import uuid; str(uuid.uuid4())There is no native v7 yet, so reach for theuuidpackage (v7() since v10) in JavaScript, oruuid_generate_v7()in Postgres 18. Whatever you use, make sure it is backed by a cryptographic random source. A generator built onMath.random()produces values that look fine and are both predictable and collision-prone.
Should you worry about collisions?
No. To reach even a one-in-a-billion chance of a single duplicate v4, you would need to generate roughly 2.7 quintillion of them. Every UUID in the batch above is unique, and the v7 generator adds a monotonic counter so that values created inside the same millisecond stay both distinct and correctly ordered. The realistic failure mode is not a collision: it is a weak random source.
Frequently asked questions
Are these UUIDs actually random?+
Yes. Every value comes from crypto.getRandomValues, the browser's cryptographically secure random source, not Math.random. A v4 UUID carries 122 random bits, so collisions are not a practical concern.
Should I use v4 or v7?+
Use v7 for database primary keys. Its first 48 bits are a timestamp, so values sort chronologically and insert sequentially into a B-tree index. Use v4 for anything where the creation time should not be inferable, like public-facing tokens or share links.
Can a UUID ever repeat?+
In practice, no. You would need to generate around 2.7 quintillion v4 UUIDs before there is a one-in-a-billion chance of a single collision. The v7 generator also adds a monotonic counter so values made in the same millisecond stay unique and ordered.
Are the generated UUIDs sent to a server?+
Never. Generation happens entirely in your browser and nothing is logged or transmitted, so these are safe to use as production identifiers.
Why does a v7 UUID reveal when it was created?+
That is by design: the timestamp is what makes it sortable. If exposing creation time is a problem for your use case, generate v4 instead.