UUID v7/v4 Generator - NanoID/ULID Online Bulk

1. Generate and use

1. Press "Generate" for a UUID v4 (e.g. 3b241101-e2bb-4255-8caf-4136c566a962).
2. Raise the count for batch generation; the list copies in bulk.
3. Toggle case and hyphens to match your primary-key format requirements.

2. Why v4 never collides

v4 has 122 random bits — about 5.3×10^36 combinations. At one billion per second for 86 years, the chance of a single collision reaches only 50%. In practice: for table primary keys, distributed trace IDs, or session tokens, you will essentially never cause a collision yourself — a unique index is just the final safety net.

3. Where UUID fits — and where it does not

• Great for: distributed primary keys / trace IDs (nodes generate independently), session and API tokens, collision-free filenames.
• Poor as a clustered database key: v4 randomness fragments B+ trees; write-heavy tables prefer auto-increment or snowflake IDs (monotonic).
• Need time-ordered IDs? Consider UUID v7 (timestamp-prefixed) — see our v4/v7 comparison article.
• Exposed UUIDs carry zero information (no sequence meaning) — unguessable, but also unreadable.

4. UUID v7: why databases prefer it

v7 is the newest version defined by RFC 9562: the first 48 bits are a Unix millisecond timestamp, the rest random. The effect is IDs naturally ordered by creation time — as a database primary key, B-tree inserts become sequential appends instead of random scatter, improving both insert performance and page-cache locality over v4. Selection in one line: v4 for external identifiers where timing is irrelevant; v7 for primary or sort keys. Note that v7 leaks creation time (milliseconds are recoverable from the ID) — for order-sensitive domains like auctions, weigh whether that is acceptable. The parser of this tool extracts the timestamp from any v7 so you can see it yourself.

5. The real tradeoffs among UUID versions

v4 (random) and v7 (time-ordered) cover most new designs: v4 carries no information and is trivially simple; v7 places a 48-bit millisecond timestamp in the high bits, preserving uniqueness while making primary keys append near-sequentially in B+trees — for clustered indexes in MySQL/PostgreSQL, v7 keys meaningfully outperform v4 on insert throughput and page splits. v1 (MAC address + time) leaks machine identity and is discouraged; v5/v8 namespace hashes suit deterministic mappings where the same input must yield the same ID (e.g. mapping an email to a stable identifier). Two alternatives worth knowing: NanoID is shorter (21 characters for UUID-grade collision odds), ideal for URLs; ULID is sortable and more readable, at the cost of case sensitivity.

6. Intuition for collision probability

• With 122 random bits in v4, the chance of a single collision after generating one billion UUIDs is roughly four in a hundred billion — engineering-wise, never.
• Real-world collisions come from implementations, not randomness: weak sources (Math.random), reused seeds, or clock rollback on distributed v1/v7 generators.
• Keep a unique index at the database layer as the backstop anyway — probability cannot save you from implementation bugs.