ID Generator.
UUID v4, UUID v7, ULID, and Nanoid. Single or batch. Decode existing IDs to see embedded timestamps. All client-side — IDs are generated in your browser using the platform's cryptographic randomness.
Which ID format to pick?
UUID v4 — 128 bits of randomness, 36-char string. The default when you just need a globally-unique identifier and don't care about ordering. Indexed rows with random UUID v4 primary keys scatter badly in B-tree databases (bad insert locality), which is why v7 exists.
UUID v7 — 48-bit Unix-millis timestamp prefix + 74 bits of randomness + version/variant bits. Same 36-char format as v4 so it drops into any UUID column. Sortable by time — sorting by the string value is equivalent to sorting by creation time within the same millisecond (ties broken randomly). Use this for new database keys.
ULID — the original time-sortable ID (2016). 26-char Crockford Base32, 48-bit ms timestamp + 80-bit randomness. Human-pasteable (no hyphens, no look-alike chars). Same time-sortability as UUID v7 but shorter and arguably more readable. Your call — UUID v7 is more standard, ULID is friendlier.
Nanoid — configurable-length URL-safe IDs. Default 21 chars ≈ same uniqueness as UUID v4 at 58% the length. No time component. Good fit when you need short shareable IDs (URL shorteners, share codes) rather than database keys.
Every ID above is generated using crypto.getRandomValues() — the same CSPRNG your browser uses for TLS key material.