Krill KitsKrill Kits// A swarm of small, sharp tools for letters, numbers, and units.
§ 01 / TOOL

UUID Generator.

STATUS READYVERSIONS v4 + v7SOURCE CSPRNG
> CONFIG
COUNT 1
// VERSION
// COUNT
// FORMAT
§ 02 / ABOUT

How this generator works.

A UUID is a 128-bit number — 16 bytes — usually rendered as 32 hex digits with hyphens: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx. The M digit is the version; the leading bits of N are the variant. Both versions here use the OS-backed cryptographic random source via crypto.randomUUID() or crypto.getRandomValues().

// V4 — RANDOM

122 bits of entropy. No structure, no information leak. The default for most use cases — session IDs, public-facing references, any time you need a unique value with no ordering or correlation between IDs.

// V7 — TIME-ORDERED

First 48 bits encode a Unix-millisecond timestamp; the remaining 74 bits are random (after subtracting version + variant bits). Same uniqueness guarantees as v4 in practice, but the timestamp prefix means UUIDs sort in creation order. This is huge for database indexes — v7 inserts are append-friendly to B-trees while v4 scatters writes randomly.

Recommended for: new database primary keys (Postgres 18+ ships uuidv7() natively), event IDs, anywhere you want chronological ordering for free.

// FORMAT TOGGLES

  • UPPER — uppercase hex digits. Some legacy systems require this.
  • { BRACES } — wraps with curly braces. Common in C# / .NET interop.
  • NO HYPHENS — strips the four hyphens. Useful for compact storage or URLs.

// BATCH GENERATION

Pick a count preset (1, 5, 10, 50, 100) and hit Generate. Use COPY ALLfor a newline-separated dump suitable for pasting into a database fixture, a test file, or a config.

§ 03 / FAQ

UUID questions.

What’s the difference between v4 and v7?+
v4 is fully random — 122 bits of entropy, no pattern, no information leaked. v7 is timestamped — the first 48 bits are a Unix-millisecond clock, the rest is random. v4 is the default for most use cases. v7 is the modern choice for database primary keys because it sorts chronologically (great for B-tree index locality) without sacrificing uniqueness.
Are these cryptographically random?+
Yes. Both versions pull random bytes from crypto.getRandomValues() (or crypto.randomUUID() for v4 when available), which is the browser’s OS-backed CSPRNG — the same source TLS, password reset tokens, and similar use. Don’t roll your own RNG; this one is fine.
How likely is a collision?+
For v4: about 1 in 2.71 quintillion. You’d need to generate a billion UUIDs per second for ~85 years to hit a 50% collision chance. For v7, the timestamp prefix means same-millisecond collisions only fight over the remaining 74 random bits — still effectively impossible at any realistic rate.
When should I use v7 over v4?+
Database primary keys, anywhere ordering matters, or when you want to avoid index fragmentation. v4 randomly scatters insertions across the B-tree, which thrashes cache. v7 inserts are append-only and benefit from locality. Some database engines (Postgres 18+, modern MySQL) explicitly recommend v7 for new schemas.
Does anything leak from a v7 UUID?+
The timestamp. Anyone who reads a v7 UUID can extract the exact millisecond it was generated. For internal IDs that’s usually fine (and often useful for debugging). For public-facing IDs where you don’t want creation order leaked, use v4.
What about v1, v3, v5, v6?+
v1 leaks your MAC address — avoid. v3 and v5 are name-based (deterministic from a namespace + name) — only useful for specific cases like generating the same ID for the same input. v6 is a v1 variant with reordered bits — niche. v4 and v7 cover ~99% of real use cases.
§ 04 / TOOLS

Related calculators.

§ 05 / READING

Deeper dives.