UUID / GUID Bulk Generator

Where Randomness Actually Matters

Not every random-looking identifier is safe to use in a security context, and it's worth being precise about where UUID v4 does and doesn't help. Because this tool uses crypto.randomUUID() — backed by the operating system's cryptographically secure pseudorandom number generator, the same entropy source used for TLS key material — the 122 random bits in each generated UUID are genuinely unpredictable, not just "look random." That property makes v4 UUIDs suitable as session identifiers, CSRF tokens, and password-reset tokens, where an attacker guessing the value would be a real security failure.

It's worth contrasting this with UUIDs generated by older or naive implementations using Math.random() — a non-cryptographic PRNG whose output can, in some engines, be predicted after observing enough prior values, making it unsuitable for anything security-sensitive even though the resulting string looks identical to a proper v4 UUID. A separate consideration: a UUID is not a secret by design in most systems — it's typically embedded in URLs, logged, and passed around as a public-ish identifier, so treat it as a hard-to-guess reference, not as a substitute for actual authentication or authorization checks on the resource it points to.

The Sequential ID That Leaked Customer Data

A company once built an invoice-download feature where each invoice's URL was simply /invoices/download/1842, with the number matching the invoice's sequential database primary key. The feature worked correctly for the customer who owned invoice 1842 — but a routine security review found that changing the number in the URL to 1841 or 1843 returned another customer's invoice PDF in full, with no ownership check on the download endpoint. Because the IDs were sequential integers, an attacker didn't even need to guess — incrementing the number in a loop would enumerate every invoice in the system.

The proper fix was two-part: adding an authorization check that verifies the requesting user actually owns the invoice being requested, and separately, replacing the sequential integer identifier with a UUID v4 in any URL or parameter exposed to end users, so that even in the absence of a broken authorization check, an attacker couldn't enumerate adjacent records by simply counting. The incident is a common and recurring pattern — sequential, guessable identifiers in public-facing endpoints turn any missing authorization check into an automatic data enumeration bug, exactly the failure mode UUIDs are designed to prevent even though they're not a substitute for the authorization check itself.

When Generated IDs Don't Behave

UUID collisions from proper v4 generation are astronomically unlikely and essentially never the actual cause of a "duplicate ID" bug in practice — when duplicates do show up, the real cause is almost always somewhere else. Check first whether the same logical record is being created twice from a retried operation (a client retry after a timeout re-submitting the same request with a freshly generated UUID rather than reusing an idempotency key) — this produces two genuinely different UUIDs referencing what should be one operation, which looks like a duplicate-record bug even though no collision occurred. Second, check for a non-cryptographic UUID library or a polyfill silently falling back to Math.random() on older browsers that lack crypto.randomUUID() — worth auditing if the generation code predates broad support for the native API.

Third, watch for storage-layer truncation — a database column defined as CHAR(32) instead of the full 36-character hyphenated format silently drops the hyphens, and comparing a truncated stored value against a correctly formatted new UUID never matches. Finally, if primary-key insert performance degrades as a table grows, the cause is usually not the UUID generation itself but B-tree index fragmentation from inserting effectively random values into a sequential index structure — worth knowing before assuming a duplicate-key error is actually a collision.

UUID v4 Next to Snowflake and ULID

UUID v4 isn't the only identifier scheme built for coordination-free generation. Snowflake-style IDs, popularized by Twitter and also used by Discord and Instagram, pack a timestamp, a machine ID, and a sequence counter into a 64-bit integer — roughly sortable by creation time and far more compact to index than a 128-bit UUID, which matters at scale since sequential-ish IDs compress better in a B-tree than the effectively random distribution of UUID v4. The tradeoff is that Snowflake requires assigning and coordinating machine or worker IDs across a fleet, reintroducing a sliver of the coordination problem UUIDs exist to avoid.

ULIDs split the difference: a 48-bit timestamp prefix followed by 80 bits of randomness, encoded in Base32 for a shorter string than a UUID, sortable lexicographically as strings — something UUID v4 cannot do — while still requiring no coordination between generators. For systems where index locality and rough chronological ordering matter, such as event logs or time-series tables, ULID is often the better fit; for maximum compatibility with existing database column types, ORMs, and tooling that already expect the standard UUID format, v4 remains the safer default.

Frequently Asked Questions