The problem: people use UUIDs without knowing which version they are getting
A UUID looks like a single thing: 550e8400-e29b-41d4-a716-446655440000. It is 32 hex digits separated by hyphens into five groups (8-4-4-4-12). But not all UUIDs are the same. The digit at position 12 (the first digit of the third group) is the version number. In the example above, the 4 at position 12 means this is a version 4 UUID — random. A version 1 UUID has a 1 there, and it encodes a timestamp. A version 7 has a 7 there, and it is sortable. Versions 3 and 5 are deterministic — the same input always produces the same UUID. The version number changes what the UUID means, how it behaves, and what it is good for.
Most developers generate UUIDs with a library that defaults to v4 and never think about it. That is usually fine — v4 is the most common and the safest default. But if you use v4 as a database primary key, your index fragments because the IDs are random. If you use v1, your IDs are sortable but leak the machine's MAC address. If you need the same UUID every time you hash a given string, you need v3 or v5. Knowing the difference is the difference between using UUIDs effectively and using them blindly.
The UUID Generator supports nine ID types: UUID versions 1, 3, 4, 5, 7, plus ULID, CUID2, NanoID, and the NIL UUID. It generates them entirely in the browser, validates them, and exports in bulk. Understanding the version differences is the difference between picking the right one and picking the default.
Fastest path
Open the UUID Generator, pick an ID type from the selector (v4 is the default), set the count (1 to 1000), pick a format (lowercase, uppercase, no-dashes, braces, or URN), and click Generate. For v3 and v5, you also need a namespace and a name. For NanoID, you can set the alphabet and length. The Validate tab decodes any UUID you paste — it tells you the version, variant, and timestamp (for v1 and v7).
UUID structure: version and variant nibbles
A UUID is 128 bits. The canonical format is xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, where M is the version nibble and N is the variant nibble. The version nibble occupies the high 4 bits of the 13th hex digit (position 12, 0-indexed). The variant nibble occupies the high 2 to 3 bits of the 17th hex digit (position 16).
550e8400-e29b-41d4-a716-446655440000
^ ^
version 4 variant 10xx (RFC 4122)
The variant field distinguishes RFC 4122 UUIDs from older NCS UUIDs and Microsoft GUIDs. The tool's validator reads both nibbles. If the variant bits are 10xx (8 through B in hex), it is an RFC 4122 UUID. If they are 0xxx (0 through 7), it is an NCS backward-compatibility UUID. If they are 110x (C through E), it is a Microsoft legacy GUID. The variant matters because it determines how the remaining bits are interpreted.
Version 4: random
UUID v4 is the most common. It uses random bits for everything except the version and variant nibbles. Of the 128 bits, 6 are fixed (4 for version, 2 for variant), leaving 122 bits of randomness. That is 2^122 possible values — approximately 5.3 times 10^36.
The tool uses crypto.randomUUID() when available (all modern browsers support it), which delegates to the operating system's cryptographically secure random number generator. If that API is unavailable, it falls back to a Math.random()-based generator that sets the version nibble to 4 and the variant nibble to 8.
UUID v4 is the default for most use cases: database IDs, API tokens, session identifiers, trace IDs. It requires no coordination between generators, works in distributed systems, and has no timing information that could leak.
Version 1: time-based with MAC address
UUID v1 encodes a 60-bit timestamp measured in 100-nanosecond intervals since October 15, 1582 — the Gregorian epoch, chosen because it predates all modern computer systems. The timestamp occupies 60 bits. A 14-bit clock sequence prevents duplicates when the system clock is rolled back. A 48-bit node identifier is traditionally the machine's MAC address.
The tool computes the timestamp using BigInt arithmetic — the Gregorian offset is 122192928000000000 100-ns intervals, which exceeds JavaScript's 53-bit safe integer range. It uses a random 6-byte node identifier instead of the actual MAC address, which avoids leaking hardware addresses while preserving the structure.
UUID v1 is sortable by generation time, which makes it useful for database indexes and log correlation. The tradeoff is that it reveals the timestamp of creation, which may be undesirable for security-sensitive contexts. It also reveals the node identifier, which in the original specification was the MAC address. The tool uses random node IDs to avoid this leak.
Version 7: sortable Unix timestamp
UUID v7 is the modern replacement for both v1 and v4. It was introduced in RFC 9562 (2024). The first 48 bits encode the Unix millisecond timestamp. The remaining 62 bits (minus the version nibble) are random. The result is a UUID that sorts chronologically — newer UUIDs sort after older ones — while still having enough randomness to avoid collisions.
01912f8a-7300-7abc-def0-1234567890ab
^
version 7
01912f8a7300 = Unix ms timestamp
The tool extracts the first 12 hex characters as the timestamp and fills the rest with random hex. Because the timestamp is at the front, UUID v7 values sort correctly as strings. This makes v7 ideal for database primary keys: sequential insertion avoids index fragmentation, and the random suffix prevents collisions across generators in the same millisecond.
If you are starting a new project and need UUIDs as database keys, use v7 instead of v4. The sortability is free — you give up nothing and gain ordered inserts.
Versions 3 and 5: namespace and name hashing
UUID v3 and v5 are deterministic. Given the same namespace UUID and the same name string, they always produce the same UUID. v3 uses MD5, v5 uses SHA-1. Everything else is identical: concatenate the namespace UUID bytes with the UTF-8-encoded name, hash the result, take the first 16 bytes, set the version and variant nibbles.
The tool provides four standard namespaces defined in RFC 4122: DNS, URL, OID, and X.500. You can also enter a custom namespace UUID. For each namespace + name pair, the tool computes the hash — using a built-in MD5 implementation for v3 (because the Web Crypto API does not support MD5) and crypto.subtle.digest('SHA-1') for v5.
Use v3 or v5 when you need the same UUID every time for a given input. Example: generating a stable UUID for a URL without storing it. UUID v5(namespace=DNS, "example.com") always produces the same UUID, so two systems independently generating an ID for the same domain get the same result. Prefer v5 over v3 — SHA-1 is stronger than MD5, and v3 is retained only for backward compatibility.
ULID, NanoID, and CUID2: alternatives to UUID
The tool supports three non-UUID identifier formats:
ULID (Universally Unique Lexicographically Sortable Identifier) is 26 characters of Crockford Base32. The first 10 characters encode a 48-bit millisecond timestamp. The remaining 16 characters are random. Like UUID v7, ULIDs sort chronologically. Unlike UUID v7, ULIDs are shorter (26 chars vs 36), case-insensitive, and use a restricted alphabet that excludes confusing characters (I, L, O, U). ULIDs are increasingly used in web applications where shorter, URL-safe IDs matter.
NanoID is a short string ID with a configurable alphabet and length. The default is 21 characters from a URL-safe alphabet (A-Za-z0-9_-), giving about 121 bits of entropy — comparable to UUID v4's 122 bits in less than 60 percent of the length. NanoID is popular for URL parameters and user-facing IDs because it is short and URL-safe. The tool lets you set the alphabet (URL-safe, hex, numeric, alpha) and length (4 to 128 characters).
CUID2 is a collision-resistant identifier designed for distributed systems. It combines a timestamp, a random fingerprint, and random suffixes into a 25-character string. CUID2 is sortable (the timestamp is at the front) and designed to be safer than the original CUID, which had entropy and security issues.
Collision probability: the birthday problem
UUID v4 has 122 random bits. The probability of a collision depends on how many UUIDs you generate. The birthday problem formula gives the probability that at least two UUIDs in a set of n are identical:
P(collision) ≈ 1 - e^(-n² / (2 × 2^122))
For n = 1 billion (10^9) UUIDs, the collision probability is about 1 in 10^21. For n = 1 trillion (10^12), it is about 1 in 10^15. The 50 percent collision point — where you would need to generate as many UUIDs as there are grains of sand on all beaches — is approximately 2.71 times 10^18 UUIDs. In practice, you will never see a v4 collision. The tool's About tab shows these numbers.
NanoID's collision probability depends on the alphabet and length. The default 21-character URL-safe alphabet gives 121 bits of entropy, comparable to UUID v4. Shorter NanoIDs have less entropy: a 12-character NanoID has about 69 bits, which is still collision-free for practical purposes (billions of IDs) but not for trillions.
Gotchas
- UUID v4 as a database primary key fragments indexes. Random IDs scatter across the B-tree, causing page splits and write amplification. For high-write databases, use UUID v7 or ULID instead — they sort chronologically and insert sequentially. If you are stuck with v4, consider using a composite key (sequential integer + UUID) or a UUID v4-to-ordered transform like UUID v6 (not in the tool).
- UUID v1 leaks timing information. The timestamp is embedded in the UUID. If an attacker can see your UUIDs, they can determine when records were created and potentially infer creation rate and business activity. UUID v7 has the same issue. If timing is sensitive, use v4.
- The tool uses random node IDs for v1, not real MAC addresses. The original RFC 4122 specification uses the machine's MAC address as the node identifier. The tool generates a random 6-byte node ID instead, which is safer but means two UUIDs generated on the same machine in the same 100-ns interval could theoretically collide. In practice, the clock sequence prevents this.
- v3 (MD5) is deprecated in favor of v5 (SHA-1). MD5 has known collision vulnerabilities. While these do not directly compromise UUID v3's uniqueness (the attack scenario is different), SHA-1 is the recommended hash for namespace-based UUIDs. The tool supports both for completeness, but you should use v5 for new systems.
- NanoID length matters more than you think. A 6-character NanoID has about 35 bits of entropy — fine for a few thousand IDs, but collisions become likely at scale. A 10-character NanoID has about 57 bits, which is safe for millions. The tool's default of 21 characters is conservative and safe for any practical use case. Do not shorten it without understanding the collision tradeoff.
Summary
- A UUID is 128 bits. The version nibble at position 12 tells you how it was generated. The variant nibble at position 16 tells you which specification it follows. The tool's validator reads both.
- UUID v4 is random, the default, and collision-free for any practical purpose (2^122 bits, 50 percent collision at 2.71 times 10^18 UUIDs). Use it when you need a random unique ID and do not care about sort order.
- UUID v7 is sortable by timestamp and should replace v4 for database primary keys. It inserts sequentially, avoiding index fragmentation. UUID v1 is also time-based but uses the Gregorian epoch and leaks timing information.
- UUID v3 (MD5) and v5 (SHA-1) are deterministic — same namespace and name always produce the same UUID. Use v5 for new systems. ULID and NanoID are shorter alternatives: ULID is sortable (26 chars), NanoID is configurable (default 21 chars, URL-safe).
- Use the UUID Generator for all nine ID types with bulk generation and validation, the Password Generator for random passwords, the JWT Decoder for inspecting JWT tokens that often contain UUIDs as claims, and the JSON Schema Generator for schemas that reference UUIDs.