ID Generator
UUID v4, time-sortable UUID v7, ULID and Nano ID — all from the browser's CSPRNG.
Uppercase
122 random bits. No ordering — rows land all over a B-tree index.
0 generated
Generate UUID v4, UUID v7, ULID and Nano ID values in bulk, for seeding a database, writing tests or filling in a fixture.
UUID v4 is 122 random bits and nothing else: it is unique, and it sorts arbitrarily. That last part is why inserting v4 keys into a database index scatters writes across the whole B-tree and slows down as the table grows. UUID v7 fixes it by putting a millisecond timestamp in the leading bits, so new identifiers sort at the end and stay index-friendly while remaining unguessable.
ULID solves the same problem in a 26-character Crockford base32 form that is shorter and case-insensitive, and NanoID trades the UUID format for a compact URL-safe string. Everything is generated from the browser’s cryptographic random source, so the values are safe to use as identifiers that must not be guessable.
The reason a randomly generated identifier can be trusted without a central authority is arithmetic rather than optimism. UUID v4 carries 122 random bits, and the birthday bound puts a 50% chance of any collision at somewhere on the order of a billion billion values — more than a system will produce in its lifetime, by a very wide margin. What matters far more in practice is where the randomness came from. A UUID assembled from Math.random() has nothing like 122 bits of real entropy behind it, and identifiers built that way have collided in production systems. Everything generated here comes from the browser cryptographic random source, which is the difference between a guarantee and a hope.
Putting a timestamp in the leading bits is what makes v7 and ULID friendly to a database index, and it is also what makes them tell the truth about when a record was created. That is usually harmless and occasionally not: an identifier exposed in a public URL then reveals sign-up order and creation time, and two of them together reveal the interval between the events. ULID offers a monotonic mode so that several values generated inside the same millisecond still sort in the order they were made, which is the detail that matters when the identifier is the thing doing the sorting rather than merely accompanying it.
Length is the other axis worth choosing deliberately. A UUID is 36 characters once its hyphens are counted, a ULID is 26 and case-insensitive, and a NanoID is 21 by default — 126 bits drawn from a 64-character URL-safe alphabet, so marginally more entropy than a v4 UUID in ten fewer characters. Shorter matters wherever a value is read aloud, typed by hand or printed on something, and case-insensitivity matters wherever it may pass through a system that changes case. Storage is the argument in the other direction: a UUID fits a native 16-byte database column, while the string forms are stored as text unless you convert them.
A UUID announces its own version, which makes an unfamiliar one readable at a glance. The thirteenth hexadecimal digit — the first character of the third group — is the version number, so a 4 there means random and a 7 means time-ordered. The first digit of the fourth group encodes the variant and is 8, 9, a or b for the standard layout used by every version in common use. A value that fails those checks is not a UUID that was generated wrongly so much as a string that was never one: a truncated hash or a hand-typed placeholder that has been travelling as an identifier.
Yes. For a large table prefer UUID v7 or ULID over v4, because their time-ordered prefix gives much better index locality on insert.
The probability is negligible at any realistic volume. All formats here draw from a cryptographic random source.
A UUID is fine as an unguessable identifier but says nothing about authorisation. For secrets and API keys use a dedicated generator with a stated entropy figure.