We use cookies and similar technologies to enhance your browsing experience, analyze site traffic, and personalize content and ads. By clicking "Accept", you consent to our use of cookies. Learn more in our Privacy Policy.
Generate random UUID (v4) / GUID values in bulk — created locally in your browser using cryptographically secure randomness.
A UUID (Universally Unique Identifier, sometimes called a GUID) is a 128-bit value used to label things without a central authority handing out IDs. This tool generates version-4 UUIDs, the random variant, and lets you produce them one at a time or in bulk so you can drop fresh identifiers straight into code, test fixtures, database seeds, or config files.
Everything runs in your browser using the built-in cryptographic random number generator. No values are sent to a server, nothing is logged, and the same code works offline once the page has loaded. That matters when the IDs you generate end up as primary keys or API tokens: you get fresh, high-quality random values without trusting a remote service to hand them out. Generate a single ID, request a few hundred for a seed script, and copy the result in one click.
Each ID is produced by crypto.randomUUID(), the standard browser API for generating a random version-4 UUID. It pulls bytes from the platform's cryptographically secure random source (the same pool used for keys and tokens), then formats them according to the spec.
What you can do here:
INSERT, or an array literal.Because generation is local, bulk output is effectively instant and works with no network connection. The randomness comes from your device, not from us, so there's no shared sequence that another user could predict or collide with.
A version-4 UUID is 32 hex digits split into five groups by hyphens, in the pattern 8-4-4-4-12:
f47ac10b-58cc-4372-a567-0e02b2c3d479
Two positions are fixed by the spec rather than random:
4 — that's the version.8, 9, a, or b — that's the variant (the two top bits are set to 10).So in the example above, the 4 in 4372 marks it as v4, and the a in a567 marks the standard variant. The other 122 bits are random. If you generate a batch you'll see those two positions stay constrained while everything else varies:
3f2a9c61-7b14-4d8e-9f02-1c6a5e8b30d4
b81e0a55-2c97-4a13-83ff-7d2e44c19a6b
UUIDs are useful anywhere you need an identifier that's unique without coordinating with a counter or sequence:
v4 UUIDs are not sortable. They're random, so inserting them as a primary key scatters writes across a B-tree index and can hurt insert performance and locality on large tables. If you need time-ordered IDs, look at a time-based scheme (such as UUIDv7 or a ULID) instead of v4.
Store them efficiently. As text a UUID is 36 characters, but it's only 16 bytes of data. Postgres has a native uuid type; MySQL/MariaDB can store it as BINARY(16). Using the right type saves space and speeds up comparisons.
Case matters in some systems. The spec treats A and a as equal, but string comparisons in your code or database might not. Pick one case and normalize on input.
Don't treat a UUID as a secret by default. v4 has plenty of entropy, but it's an identifier, not an access token — pair it with real authorization.
A version-4 UUID carries 122 random bits (128 total minus the 6 fixed version/variant bits). That's roughly 5.3 * 10^36 possible values. The practical question isn't "are two equal" but "how many can I generate before a collision is likely."
By the birthday bound, you'd need to generate on the order of a billion UUIDs before the probability of a single collision reaches even one in a billion. For any normal application — even one minting millions of IDs a day — a collision is not something you need to design around.
The one real caveat is the quality of the randomness. Collision resistance assumes a good random source. This tool uses crypto.randomUUID(), which is backed by a cryptographically secure generator, so the full 122 bits of entropy are genuinely random rather than coming from a weak Math.random()-style source.
They are the same thing. GUID (Globally Unique Identifier) is the name Microsoft uses; UUID is the term from the formal spec. Both refer to the same 128-bit format.
Version 4 means the value is generated from random data. Other versions derive the ID from a timestamp, a name hash, or the machine; v4 is the most common when you just want a random unique ID with no embedded information.
They're generated from a cryptographically secure random source, so the 122 random bits are strong. But a UUID is meant to be an identifier, not a credential — for auth, use it alongside proper access control rather than as the only secret.
It's theoretically possible but astronomically unlikely. With 122 random bits you'd need to generate on the order of a billion IDs before a collision becomes even remotely probable, so in practice you can treat them as unique.
No. Generation happens entirely in your browser using a built-in API. Nothing is uploaded, logged, or saved on a server, and the tool works offline after the page loads.
Use one when records are created across multiple services or by offline clients, since it avoids coordinating a shared counter. The tradeoffs are larger storage and, for random v4, worse index locality on big tables.
The spec treats them as equal, so the same UUID can be written either way. But comparisons in your code or database may be case-sensitive, so pick one form and stick to it.
You can request a batch and get them all instantly, since generation is local. Output is one per line so you can paste it straight into a file, a SQL statement, or an array.