UUID Generator
Create UUID v1 (timestamp), v4 (random), v7 (time-ordered), or the Nil UUID. Generate one or up to a hundred at once, pick an output format, or paste a UUID below to check whether it's valid.
Validate a UUID
Versions
UUID v1 encodes a 60-bit timestamp plus a random node identifier. It's sortable by creation time and older than v7, but leaks the generation time of every value — rarely a good choice unless something you're integrating with specifically expects it.
UUID v4 is 122 bits of random data. It's the most common version and has no detectable structure — good for tokens, file names, or anywhere you just need a unique value.
UUID v7 starts with a 48-bit millisecond timestamp, followed by random bits. Because it's time-ordered, it sorts naturally and keeps database indexes from fragmenting — useful as a primary key instead of an auto-increment integer or a v4.
Nil UUID is the constant 00000000-0000-0000-0000-000000000000 —
every bit is zero. Used as a placeholder or sentinel value to mean "no ID", not for generating
unique values.
Output formats
550e8400-e29b-41d4-a716-446655440000550E8400-E29B-41D4-A716-446655440000550e8400e29b41d4a716446655440000{550e8400-e29b-41d4-a716-446655440000}urn:uuid:550e8400-e29b-41d4-a716-446655440000Which version should I use?
- Database primary key - v7. Sorts with insertion order, keeps B-tree indexes from fragmenting.
- Session or API token - v4. No embedded timestamp to leak, no ordering to matter.
- Public URL slug or file name - v4. Doesn't reveal when the resource was created.
- Distributed event ID needing rough time order without coordination - v7.
- Interop with a legacy system expecting a MAC+timestamp ID - v1.
- "No ID" / empty placeholder field - Nil UUID.
Where's v3 and v5?
v3 (MD5) and v5 (SHA-1) are deterministic, namespace-based versions - the same input namespace
and name always produce the same UUID. They're a hashing operation, not a random-generation one,
so they don't fit a "click to generate" tool: you'd need to supply a namespace UUID and a name
string, and the output is reproducible rather than novel. If you need one, it's a single call to
uuid.uuid5(namespace, name) in most standard libraries rather than something worth
generating here.
Questions
What is a UUID?
A 128-bit value used to identify something without a central authority handing out IDs — also called a GUID on Windows. Looks like 550e8400-e29b-41d4-a716-446655440000. Two randomly generated v4 UUIDs colliding is practically impossible: you'd need billions generated per second for decades before it became likely.
Why would I use v7 instead of v4?
Mainly for database primary keys. A v7 UUID embeds a timestamp, so new rows insert in roughly sorted order — a random v4 spreads inserts across the whole index and causes more page splits. For anything that isn't a DB key (session tokens, API keys, file names), v4 is fine.
What's the point of v1 or a Nil UUID?
v1 exists mostly for backward compatibility with older systems that generate it from a timestamp and network interface — v7 does the sortable-timestamp job better without exposing as much. The Nil UUID (all zeros) isn't really "generated" at all; it's a fixed constant some APIs use to represent an empty or unset ID field.
Is a UUID the same as a GUID?
Yes. GUID is just Microsoft's name for the same 128-bit format — they're interchangeable.
Are these good enough to use as security tokens?
Yes — generation uses crypto.randomUUID() and crypto.getRandomValues(), the browser's cryptographically secure random number source, not Math.random().
Does anything get sent to a server?
No. Generation and validation both run in JavaScript in your browser. Nothing here makes a network request.
How much randomness does a v4 UUID actually have?
122 bits - the other 6 of the 128 total are fixed to mark the version and variant. That's roughly 5.3 × 1036 possible values. Brute-forcing or guessing one isn't a realistic attack; the birthday-paradox collision risk is what's usually quoted (billions per second for years before a collision becomes likely), and it's unrelated to guessing a specific value.
Do v7 UUIDs sort correctly as plain strings?
Yes. The 48-bit millisecond timestamp sits in the first 6 bytes, printed first, so lexicographic (string) ordering matches chronological ordering - no need to parse the UUID to sort a list of them by creation time.
What happens if two v7 UUIDs are generated in the same millisecond?
The shared timestamp prefix ties, and the remaining ~74 random bits break the tie in effectively random order. They stay unique, but two IDs from the same millisecond aren't guaranteed to sort in the exact order they were created - only down to millisecond granularity.
Is this the same as a ULID?
Similar idea, different encoding. A ULID is 128 bits like a UUID (48-bit timestamp + 80 random bits) but is conventionally written as 26 Crockford-base32 characters instead of the dashed hex format. UUID v7, standardized later, brought the same sortable-timestamp property into the existing UUID format and RFC - which is why v7 has mostly replaced ULID for new designs.