🆔 UUID v4 Generator

v1 encodes the current timestamp and MAC address — temporal ordering but leaks infrastructure details. v4 is fully random (122 random bits) — reveals nothing about time or host, the most widely used version for database primary keys. v7 (RFC 9562, 2024) combines a millisecond timestamp prefix with random bits — gives you both randomness and sortability without leaking hardware details. For new systems in 2024+, v7 is worth considering for database performance. For existing systems: v4 is fine and universally supported.

A ULID (Universally Unique Lexicographically Sortable Identifier) encodes a 48-bit millisecond timestamp followed by 80 random bits in a 26-character Crockford Base32 string (e.g., 01ARZ3NDEKTSV4RRFFQ69G5FAV). Key advantages: ULIDs sort chronologically as strings (improving database index performance — new records insert at the B-tree end), they are URL-safe, and slightly shorter than hyphenated UUID format. Use ULIDs when insert order matters for performance or when you want IDs with an implicit timestamp.

UUID v4 has 122 random bits, giving 2^122 ≈ 5.3 × 10^36 possible values. If you generate one billion UUIDs per second continuously for 85 years, the probability of any collision is approximately 50%. For any realistic application — even large-scale distributed systems generating millions of records daily — collision probability is so small it is effectively impossible. The scenario to avoid is using a broken or seeded random number generator rather than a true CSPRNG.

Auto-incrementing integers: faster for sequential inserts in B-tree indexes, smaller storage (4-8 bytes vs 16 bytes for UUID), and simpler to work with. Downsides: expose object counts, make distributed ID generation without coordination difficult. UUIDs solve all three at the cost of index fragmentation and larger storage. Practical recommendation: use auto-increment for simple single-database applications. Use UUID v4 or v7 when you have distributed writes, need to generate IDs client-side before a database round-trip, or want to obscure record counts in public-facing URLs.

The nil UUID is all zeros: 00000000-0000-0000-0000-000000000000. It is the UUID equivalent of null — representing 'no UUID' or an unset UUID field. The max UUID (ffffffff-ffff-ffff-ffff-ffffffffffff) serves a similar purpose in some systems. Neither is generated by this tool since they are special fixed values, not random. Use the nil UUID as a default value for a UUID column before assignment or as a sentinel in an API response indicating a field has not been set.

Yes. The output is valid RFC 4122 UUID v4 — the same format produced by uuid.v4() in Node.js, UUID.randomUUID() in Java, str(uuid.uuid4()) in Python, and crypto.randomUUID() in modern browsers. The format is xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx where 4 is the version marker and y is 8, 9, a, or b for the variant. Copy any generated UUID directly into your application, database insert, or API call.

The JSON Formatter structures request/response payloads containing UUIDs. The JWT Decoder inspects tokens where UUIDs appear as the sub (subject) claim. The Base64 Encoder encodes UUIDs for use in URLs or headers. The Fake Data Generator produces complete test records with realistic names and emails that you can pair with generated UUIDs as primary keys. All are in the Dev Tools section.