UUID Generator

A UUID (Universally Unique Identifier) is a 128-bit value formatted as 36 characters (32 hex + 4 hyphens) used to uniquely identify resources across systems without a central coordinator. UUIDs follow the RFC 4122 specification.

Yes — UUID v4 takes 122 random bits from a cryptographically strong random number generator (the Web Crypto API in browsers). The remaining 6 bits encode the version (4) and variant (RFC 4122).

Not strictly guaranteed, but the probability of a v4 collision is so small it can be treated as zero in practice. You'd need to generate billions of UUIDs every second for centuries to have any meaningful collision risk.

Theoretically yes, but the odds are vanishingly small for v4. A single collision in v4 would require roughly 2.71 × 10¹⁸ generated UUIDs before reaching a 50% chance of one collision — far beyond any realistic workload.

Use v4 for most general-purpose IDs. Use v7 for database primary keys that benefit from time-ordering (indexes stay tight). Use v6 when you need v1-like time data but in a sortable order. Use v1 only when you specifically need MAC + timestamp embedding.

v4 UUIDs are unpredictable and safe to use as IDs — but they are not secrets. Don't use UUIDs as authentication tokens, session keys or to authorize access. For those, use a dedicated cryptographically-random token instead.

A UUID is 128 bits (16 bytes). In its canonical text form it's 36 characters: 32 hex digits plus 4 hyphens. Stripped of hyphens it's 32 characters.

UUIDs can be generated anywhere — on the client, across distributed services, or offline — without coordinating with a database. They also avoid leaking row counts and don't reveal creation order (except for v6/v7, which intentionally do for sortability).

v1 encodes a 60-bit timestamp and the generating machine's MAC address — useful for sorting by creation time but slightly reveals where it was generated. v4 is purely random with no embedded data — privacy-safer and the most common choice.

UUID v7 prefixes the value with a 48-bit Unix timestamp (millisecond precision), making UUIDs sortable in time order. This is ideal for database indexes — they pack tightly and stay in B-tree order, dramatically improving insert performance compared to random v4 IDs.