UUID v4 vs Other Versions: Random vs Time
A UUID is 128 bits written as 8-4-4-4-12 hex. RFC 9562 (May 2024, obsoletes RFC 4122) puts the version in the first nibble of the third group and the variant in the first bits of the fourth. Version 4 fills the other 122 bits from a CSPRNG; crypto.randomUUID() is that form. v1 and v6 embed a Gregorian 100-nanosecond clock; v7 embeds Unix milliseconds; v3 and v5 hash a namespace plus name (MD5 vs SHA-1). Docify mints v4 only. Nothing is uploaded.
The same 36-character shape is not one algorithm. The version nibble says whether the remaining bits are random, a clock, or a name hash. The live UUID generator calls crypto.randomUUID() and does not implement the other versions.
Shared layout, different payload
Version M and variant N
RFC 9562 §4 writes every UUID as five hex groups. The first digit of the third group is the 4-bit version. The first two bits of the fourth group are the variant; variant 10 makes that digit 8, 9, a, or b. Changing case or stripping hyphens does not change those bits.
That string is RFC 9562 Appendix A.3’s UUIDv4 example: the 4 in 4320 is the version; the 9 in 9bac is a legal variant-10xx nibble.
Random vs clock vs name
v4: 122 random bits
RFC 9562 §5.4 fills random_a, random_b, and random_c (122 bits) from a random or pseudorandom source, then overwrites the version (4) and variant (10). WHATWG crypto.randomUUID() is specified as that version 4 UUID. Successive values are not time-ordered. Section 1 of the RFC notes the B-tree locality cost of inserting them as primary keys. They still are not secrets and are not checked against a registry here.
v1 and v6: Gregorian 100-nanosecond time
UUIDv1 (§5.1) stores a 60-bit count of 100-nanosecond intervals since 00:00:00.00, 15 October 1582 UTC, plus a 14-bit clock sequence and a 48-bit node field (often a MAC). The timestamp is split low / mid / high, so a lexical sort of the 36-character string is not chronological. UUIDv6 (§5.6) uses the same clock but stores the 48 most significant time bits first so the string sorts with time. The RFC says systems without a v1 legacy should use v7 instead. A node field that is a MAC can identify a machine; this page never reads a MAC.
v7: Unix milliseconds in the high bits
UUIDv7 (§5.7) puts a 48-bit Unix epoch timestamp in milliseconds (since 1970-01-01T00:00:00Z, leap seconds excluded) in bits 0–47, then version 7, then 74 remaining bits that are random or an optional monotonic counter. Implementations SHOULD use v7 instead of v1 or v6 when they want a time-ordered UUID. Docify does not mint v7 and does not extract a clock from a pasted string.
v3 and v5: namespace plus name
Both versions hash a 16-octet Namespace ID concatenated with a name (§6.5). v3 uses MD5 (§5.3); v5 uses SHA-1 and keeps the leftmost 128 bits of the 160-bit digest, discarding the rest (§5.5). The version and variant bits then overwrite the matching hash bits. The same namespace and name always yield the same UUID. The RFC prefers v5 over v3. A SHA-256 name-based ID MUST be UUIDv8, not v5. Docify’s hash generator can compute SHA-1 or MD5 of text, but it does not assemble a name-based UUID.
Versions this generator does not mint
v2, v8, and ULID
Version 2 is reserved for DCE Security and is not specified as a generation algorithm here. UUIDv8 (§5.8) leaves 122 bits for an implementation-defined layout; the RFC says it is not a replacement for filling those bits with v4 random data. ULID is a different 128-bit identifier (typically 26 Crockford base32 characters), not a UUID version nibble. None of these come from crypto.randomUUID().
Generate RFC version 4 UUIDs
crypto.randomUUID() in the browser. Not v1, v5, or v7. Nothing is uploaded.
Use UUID Generator →FAQ
- Does Docify generate v1, v5, or v7 UUIDs?
- No. The live generator calls crypto.randomUUID() only. That API returns a version 4 UUID (36-character 8-4-4-4-12 hex, version nibble 4, RFC variant 10xx). It does not mint v1, v2, v3, v5, v6, v7, v8, ULID, or namespace IDs. Uppercase and Remove hyphens reformat stored strings and do not change the version.
- How do I read the version from a UUID string?
- The version is the first hexadecimal digit of the third group (the M in xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx). RFC 9562 Appendix A.3’s example 919108f7-52d1-4320-9bac-f847db4148a8 is version 4 because that digit is 4. The first digit of the fourth group (N) is the variant: 8, 9, a, or b means variant 10xx.
- Why does RFC 9562 prefer v7 over v4 for some database keys?
- Section 1 notes that UUIDv4 values created in succession are not close in a B-tree index, so inserts land at random locations. UUIDv7 puts a 48-bit Unix millisecond timestamp in the most significant bits so later values sort after earlier ones. That is a layout choice, not a uniqueness proof. Docify does not generate v7.
- Is a v4 UUID a secret or proof that no one else has the same ID?
- No. A v4 UUID is 122 bits of CSPRNG output plus the version and variant bits. This site does not check a registry, mint sequential IDs, or treat the string as a password, session token, or signed claim. crypto.randomUUID() still requires a secure context (HTTPS or localhost); there is no Math.random() fallback.