UUID v1 vs v4: Which One Should You Actually Use?

Most people reach for "a UUID" the same way they reach for "an ID" - without thinking about which version, or that versions even exist. Then a code review comment mentions "why is this a v1 UUID" and it turns out someone, somewhere, picked a construction method that quietly leaks the server's clock and a fragment of its network identity into every record. The two versions you'll actually encounter, v1 and v4, are built from completely different ingredients, and the choice between them is really a choice about what you're willing to reveal.

What a UUID Actually Guarantees

A UUID (Universally Unique Identifier) is a 128-bit value, conventionally written as 32 hex digits split into five hyphenated groups, like f47ac10b-58cc-4372-a567-0e02b2c3d479. It doesn't guarantee mathematical uniqueness the way a database auto-increment column does - it guarantees uniqueness is overwhelmingly probable given how the bits are generated, to the point that collisions are treated as effectively impossible for practical purposes. What a UUID guarantees beyond that depends entirely on its version, because different versions encode completely different information into those 128 bits.

How v1 Is Built: Timestamp Plus Node

A version 1 UUID packs in a 60-bit timestamp (the number of 100-nanosecond intervals since October 15, 1582 - yes, really, that's the reference point the spec chose), a clock sequence used to avoid collisions if the clock moves backward, and a 48-bit "node" identifier that the original spec intended to be the generating machine's MAC address. The practical result of this design is that v1 UUIDs generated close together in time on the same machine share a recognizable node segment and have timestamps that sort in roughly the order they were created - which is exactly why some people like v1 for database primary keys: it's a UUID that isn't fully random with respect to insertion order, which can help with index locality in some databases.

That same design is also the downside. A v1 UUID leaks the approximate moment it was generated to anyone who knows how to decode it, and historically, MAC-address-based node fields have been used to fingerprint or correlate records back to a specific physical machine. Neither of those is usually the deal-breaker on its own, but it's metadata you're handing out by default, whether or not anyone downstream will ever need it.

How v4 Is Built: (Almost) Pure Randomness

A version 4 UUID is far simpler: generate 122 random bits, then fix a small handful of specific bits to mark the UUID as version 4 and set the variant field per the spec. That's the entire recipe - no timestamp, no machine identifier, nothing derived from when or where it was created. Two v4 UUIDs generated a millisecond apart on the same machine look nothing alike, and there's no way to recover "when was this created" or "which server made this" just by staring at the value. That's precisely why v4 is the sensible default for most application-level IDs: it reveals nothing about its own origin, which means you never have to think about whether that leakage matters for your use case.

A Caveat About This Site's Generator

Worth being upfront about, since it directly affects whether you should rely on this particular tool for anything beyond quick testing or mock data: the UUID generator on this site implements v1's field layout, but not the underlying data sources the spec assumes. Its "timestamp" fields are derived from Date.now() - the real current time in Unix-epoch milliseconds - but they're sliced directly into the v1 timestamp fields rather than converted into the 100-nanosecond-since-1582 format the spec actually calls for. A fully spec-compliant v1 parser reading the timestamp back out of one of these UUIDs would not recover today's date; it would compute a value based on the wrong epoch and the wrong tick resolution. And the 48-bit "node" field, which per spec is meant to be a stable identifier for the generating machine (a real MAC address, or a fixed randomly-generated substitute when no MAC is available), is instead freshly randomized on every single call - so it doesn't identify anything, and it isn't even consistent across two UUIDs generated back-to-back on this page.

The v4 generator has its own asterisk: it draws its "random" bits from Math.random(), which is a fast pseudorandom number generator, not a cryptographically secure one (crypto.getRandomValues() would be the CSPRNG-backed choice). For generating placeholder IDs, test fixtures, or mock data - the situations this tool is actually built for - that distinction doesn't matter. It would matter if you were generating something like a password-reset token or a session identifier that needs to be unpredictable to an attacker, which is not what a UUID field on a form is for anyway. Just don't take either version's output here as evidence of a genuinely time-encoded or cryptographically random identifier if your use case actually depends on that specific guarantee.

Which One Should You Pick?

For the overwhelming majority of application IDs - user accounts, orders, session records, API resource IDs - v4 is the right default, precisely because it reveals nothing and requires no thought about what it might leak. Reach for v1 (or a proper time-ordered alternative like ULID or UUIDv7, if your stack supports it) only when you specifically want rough creation-time ordering baked into the identifier itself, and you've already decided you're fine with the timestamp and machine-fingerprint trade-off that comes with it. When in doubt, v4 is the one that doesn't require you to have made that decision at all.

You can generate either version, in bulk, with the UUID Generator - useful for seeding test data or filling in placeholder IDs while you build, with the caveats above in mind for anything more demanding than that.