How to generate UUIDs
- Set how many identifiers you need, up to a thousand at a time.
- Choose version 4 for pure randomness, or version 7 if you want them to sort by creation time.
- Pick the format your code expects, standard, uppercase, without hyphens, braced or quoted.
- Press Generate. Press it again for a completely new set.
- Copy them all, or download them as a text file.
What this generator produces
- RFC 4122 version 4 UUIDs with the correct version and variant bits set.
- Version 7 identifiers with a millisecond timestamp in the leading bits, so they sort chronologically.
- The nil UUID, for when you need an explicit empty value.
- Five output formats including a quoted, comma-separated form ready to paste into code.
- Cryptographic randomness from the browser, never Math.random.
- Bulk generation of up to a thousand identifiers in one press.
What a UUID is and why the format matters
A UUID is a 128-bit number, written as 32 hexadecimal digits in five hyphenated groups. The point is that anything can generate one at any time without asking a central authority, and the chance of two matching is small enough to ignore.
How small is worth stating properly. A version 4 UUID has 122 random bits. To reach a 50 per cent chance of a single collision you would need to generate around 2.7 quintillion of them. Generating a billion a second, you would need roughly 85 years. In practice, collisions do not happen.
Version 4 versus version 7
Version 4 is entirely random, which is exactly what you want for anything unguessable, session identifiers, public object references, tokens.
That randomness is a problem for databases. Insert random UUIDs as a primary key and each one lands in an arbitrary position in the index, scattering writes across the whole structure. On a large table this measurably degrades insert performance and bloats the index.
Version 7 fixes it by putting a millisecond timestamp in the leading bits. New identifiers are always larger than older ones, so they append to the end of the index like an auto-incrementing integer while remaining globally unique. If you are choosing a primary key type today, version 7 is usually the better answer, but check your database supports it, since it is a recent addition.
Where the randomness comes from
This matters more than people assume. Identifiers generated with Math.random are predictable: the underlying generator is not cryptographic, and given enough output an attacker can work out its state and predict subsequent values. If your UUIDs are session tokens, that is a complete compromise.
This generator uses the browser's crypto API, which draws on the operating system's entropy pool. The status line says which source was used, and warns you if a fallback was necessary.
Formats and where each belongs
- Standard lowercase: the canonical form, and what almost everything expects.
- Uppercase: required by some Microsoft tooling and older Windows APIs.
- No hyphens: saves four characters where storage is tight, common in URL paths.
- Braced: the Windows registry and COM convention.
- Quoted with commas: ready to paste straight into an array in code or a SQL IN clause.
All of these represent the same 128-bit value, so a system storing UUIDs as binary treats them identically. For other kinds of random values, the password generator and random number generator use the same cryptographic source. Nothing is generated on a server, so no identifier you create is ever known to anyone else.
Storing UUIDs efficiently
How you store a UUID matters more than how you generate it. Written out as text it occupies 36 characters. Stored as binary it takes 16 bytes. On a table with millions of rows and an index on that column, the difference is substantial in both disk and memory.
Most databases have a native type for this, uuid in PostgreSQL, BINARY(16) in MySQL, uniqueidentifier in SQL Server. Using a text column instead is the commonest mistake, and it compounds the index-scattering problem that version 4 UUIDs already cause.
When not to use a UUID
UUIDs are not always the right identifier. They are long, awkward to read aloud, impossible to remember and unpleasant in a URL a human might type. For anything customer-facing. An order reference, a booking code. A shorter human-friendly identifier is usually better, with a UUID kept internally if you need one. Using a UUID everywhere by default is a habit worth questioning rather than a best practice.