UUID / GUID Bulk Generator

UUID Randomness as a Security Property

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.

How Sequential IDs Turn Into an Enumeration Problem

A common and well-documented vulnerability class, formally known as Insecure Direct Object Reference (IDOR), shows up whenever a resource is addressed by a predictable identifier and the endpoint serving it doesn't independently verify that the requester is actually authorized to access that specific resource. Auto-incrementing integer primary keys are the most frequent trigger, because they turn "guess a valid identifier" into "count upward from one you already have" — a caller who legitimately owns record 1842 doesn't need to guess anything to check whether 1841 or 1843 belongs to someone else; the sequence enumerates them automatically.

The fix has two independent parts, and neither substitutes for the other. First, every endpoint that serves a resource by ID needs an explicit ownership or permission check scoped to that specific resource, not just a check that the caller is authenticated at all. Second, replacing a sequential integer with a UUID v4 (or any sufficiently random identifier) in any URL or parameter exposed to end users removes the enumeration shortcut even if an authorization check is later found to be missing or buggy — it doesn't fix a broken authorization check, but it does mean a broken check fails safely, since an attacker who doesn't already hold a valid identifier has no way to find one, rather than failing open to anyone willing to increment a number in a loop.

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