UUID structure under RFC 9562
A UUID is 128 bits. The common text representation is 32 hexadecimal digits in groups of 8-4-4-4-12. RFC 9562 obsoleted RFC 4122 in May 2024 and clarifies the variant and version bits, network byte order, modern versions 6 through 8, security considerations and database guidance. GUID is widely used as a synonym, although some Microsoft binary encodings have byte-order conventions outside this page’s text-format scope.
For the RFC 9562 variant, the two most significant bits of octet 8 are 10. The four most significant bits of octet 6 hold the version. UUIDv4 fixes those version bits to 0100 and fills every other available bit with random or pseudorandom data. That leaves 122 random bits. This implementation requests all source bytes from the browser’s cryptographic random generator and then overwrites only the required version and variant bits.
UUIDv7: sortable time prefix with an explicit privacy trade-off
UUIDv7 places a 48-bit unsigned Unix Epoch timestamp in milliseconds into the first six bytes. It sets the version to 7 and RFC variant to 10, leaving 74 bits for random data or optional monotonicity techniques. RFC 9562 recommends v7 over v1 and v6 when possible because it uses the familiar Unix timestamp and offers better entropy characteristics.
This browser generator chooses the specification’s simple random method: each v7 receives fresh random data in the remaining 74 bits. UUIDs from later milliseconds sort after earlier milliseconds in canonical byte order. Values created during one millisecond are not promised to follow generation order because their random fields can sort either way. A database system needing strict per-node monotonicity should use a tested library or server/database function with documented clock rollback, counter overflow, process restart and multi-node behavior.
The timestamp is visible, not encrypted. Anyone holding a v7 can recover its nominal millisecond creation time, although RFC 9562 does not require that embedded time exactly match real clock time. Choose v4 if that metadata is unwanted. Never infer authorization, ownership or business event time from a UUID alone.
Bulk formatting and database use
Canonical lower-case text is the most interoperable default. Compact, braces and URN representations are formatting choices around the same 128 bits. Uppercase and lowercase hexadecimal compare to the same value in a UUID-aware system, but ordinary case-sensitive strings may not. Normalize at input boundaries rather than letting several representations become distinct records.
Plain output is convenient for terminals and fixtures. JSON creates an array of strings. CSV includes a one-based index and a quoted UUID column. SQL produces parenthesized string tuples suitable for review and adaptation, not a full statement tied to a table or dialect. Downloaded values are not remembered by this site.
RFC 9562 notes that binary storage uses less space and can improve access, while text can reduce translation work. UUIDv7 can improve B-tree insertion locality compared with random v4 values, but schema design, database UUID types, replication, index fill factors and workload matter more than a generic promise. Keep a unique constraint and handle conflicts even when collision probability is tiny.
Validation, variant and timestamp interpretation
A regular expression can confirm the 8-4-4-4-12 shape but cannot fully explain a UUID. The inspector first normalizes the text into 16 bytes, then identifies the variant from octet 8. Only the RFC variant uses the version table defined by RFC 9562. Nil is all zero bits and Max is all one bits; they are special sentinel values rather than normal v0 or v15 identifiers.
The inspector decodes v7’s first 48 bits as Unix milliseconds. It also decodes v1 and v6 Gregorian timestamps for debugging existing data, while intentionally not generating those versions. A decoded timestamp shows what the UUID contains, not proof that the clock was correct or that the identifier was created by a trustworthy system.
Collision probability is not an integrity control
UUIDv4 offers 122 random bits after fixed fields. Under the birthday model, collision probability grows with the square of the number generated, not simply with one draw. That probability is extremely small for normal application volumes with a correct CSPRNG, but faulty randomness, cloned generator state and implementation bugs can dominate the mathematical estimate. High-consequence applications require defense in depth rather than a slogan that collisions are “impossible.”
A UUID also has no checksum or signature. A one-character change can still form a structurally valid UUID that points elsewhere. RFC 9562 explicitly warns not to use UUID possession as a security capability. Use access control for authorization and a MAC or digital signature when tamper detection is required.
Privacy and runtime boundary
Generation, formatting, parsing and file creation run locally. Generated identifiers are not sent to an EasyTool endpoint, added to the address bar or retained in local storage. Clipboard access happens after a copy action. Browser extensions, clipboard managers and the database or editor where you paste values remain outside this page’s privacy boundary.
The batch limit is 5,000 to keep rendering, clipboard operations and accidental fixture creation manageable on mobile devices. Generate through an application library or database facility for production-scale allocation and test its behavior under concurrency and clock rollback.
Standards and implementation references
- IETF RFC 9562: Universally Unique IDentifiers (UUIDs)
- W3C Web Cryptography API: Crypto, getRandomValues and randomUUID
Editorial and implementation review: 2026-08-02. RFC test vectors, fixed version and variant bits, deterministic v4/v7 generation, normalization, timestamp decoding, batch limits and exports are covered by tests.
Frequently asked questions
Should I use UUIDv4 or UUIDv7?
Use v4 when you want a random identifier without an embedded creation time. Consider v7 when time-ordered database locality is useful and exposing millisecond-level creation time is acceptable. Your database and threat model remain authoritative.
Are UUIDv7 values strictly monotonic?
Not in this generator. RFC 9562 allows v7 to fill the 74 non-version and non-variant bits with fresh random data. Values sort by their 48-bit millisecond timestamp, but UUIDs generated inside one millisecond can appear in random order.
Does a UUID guarantee global uniqueness?
No system can guarantee global uniqueness without shared knowledge. Secure random UUIDs make collisions extremely unlikely in ordinary applications, but high-consequence systems still need database constraints and explicit collision handling.
Can a UUID be used as an access token?
No. RFC 9562 says implementations must not use UUIDs as security capabilities whose possession grants access. UUIDv7 also exposes a creation timestamp. Use an authentication and authorization design appropriate to the resource.
What input does the UUID inspector accept?
The inspector accepts canonical hex-and-dash UUIDs, 32-digit compact values, braces and urn:uuid prefixes. It reports variant before interpreting the version and decodes timestamps for v1, v6 and v7 when representable.
Are generated UUIDs uploaded or saved?
No. Generation, formatting, validation and export run locally. The page does not place generated values in the URL or browser storage. Clipboard and downloads occur only after you press the corresponding button.