UUID v4 Batch Generator
How it works
UUIDs (Universally Unique Identifiers, RFC 4122) are 128-bit identifiers formatted as 8-4-4-4-12 hexadecimal groups (xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx), where M encodes the version and N encodes the variant. Version 4 UUIDs are randomly generated — 122 bits of randomness (the other 6 bits encode version/variant). This tool generates batches of cryptographically random UUID v4 values using the browser's CSPRNG.
**Collision probability** The probability of generating two identical UUID v4s from separate generation events is approximately 1 in 2^122 (5.3 × 10^36). To have a 50% chance of a collision, you would need to generate 2.71 × 10^18 UUIDs. At 1 billion UUIDs/second, this would take 86 years. For all practical purposes, UUID v4 collisions are impossible.
**UUID v4 vs v1 vs v7** UUID v1: time-based using MAC address and timestamp — encodes when and where it was generated (privacy concern). UUID v4: fully random — no temporal ordering. UUID v7: new standard (2022) — time-ordered random UUID. The first 48 bits are a millisecond-precision Unix timestamp, enabling database index efficiency (monotonically increasing, fewer B-tree page splits) while retaining randomness in the remaining bits. For new database primary key design, UUID v7 is preferred over v4.
**Database usage** UUID primary keys enable globally unique IDs without a central sequence generator (suitable for distributed systems). The downside: UUID v4 is random, causing B-tree index fragmentation on insert-heavy workloads. Use UUID v7 or ULID for database primary keys.
Frequently Asked Questions
- UUID v4 (fully random): simple, no privacy leakage (no timestamp in the ID), but causes B-tree index fragmentation on heavy insert workloads — random inserts hit different leaf nodes, causing frequent page splits and poor cache locality. UUID v7 (timestamp-ordered): the first 48 bits are a millisecond Unix timestamp, so inserts go near the end of the index (like autoincrement), dramatically improving insert performance. For write-heavy tables (>100K inserts/hour), UUID v7 is significantly better. For read-heavy or low-insert tables, UUID v4 is fine.
- Mathematically yes; practically no. UUID v4 has 122 bits of randomness (6 bits encode version/variant). To have a 50% chance of any collision, you need ~2.71 × 10^18 UUIDs. At 1 billion generated per second, this would take 86 years. In practice, the probability of a UUID v4 collision in any realistic system is astronomically low — closer to your server being struck by lightning during every request. UUID v4 is safe to treat as globally unique without collision detection.
- JavaScript: crypto.randomUUID() (browser and Node.js 15.6+). Python: import uuid; str(uuid.uuid4()). Java: UUID.randomUUID().toString(). Go: github.com/google/uuid — uuid.New().String(). Rust: uuid crate with the v4 feature. PostgreSQL: gen_random_uuid() (requires pgcrypto). MySQL 8+: UUID() for v1 (time-based); no built-in v4 (use BIN_TO_UUID(RAND_BYTES(16)) workaround). PHP: Ramsey\Uuid\Uuid::uuid4()->toString().
- UUID v3 (MD5) and v5 (SHA-1) are deterministic: UUID = hash(namespace_uuid + name). The same namespace + name always produces the same UUID. This is useful for generating stable IDs for known entities: URL namespace + 'https://example.com' always produces the same UUID. v5 (SHA-1) is preferred over v3 (MD5). These are not random and not suitable for primary keys where uniqueness across arbitrary inputs is needed — they are for converting existing identifiers into UUID format deterministically.