Text & dev
UUID Generator
Generate random version 4 UUIDs — universally unique identifiers — one at a time or in bulk up to fifty at once. A UUID is a 128-bit value written as 36 characters in the familiar 8-4-4-4-12 pattern, like 3f29c1e8-7a4b-4c2d-9e10-6b5a8d2f1c34. Developers use them for database primary keys, distributed system identifiers, file names, idempotency keys and anywhere two independent machines must mint IDs without coordinating. Because version 4 UUIDs are filled almost entirely with random bits, collisions are effectively impossible in practice. This generator uses the browser's built-in crypto.randomUUID(), which draws from a cryptographically secure random source, so the values are suitable for production use. Toggle uppercase or strip the hyphens to match your schema, then copy a single ID or all of them at once. Generation happens locally — nothing is sent anywhere.
Options
Click Generate to create UUIDs.
Version 4 (random) UUIDs from crypto.randomUUID(). One per line; copy all grabs every value.
How the UUID generator works
Each click calls crypto.randomUUID() once per requested ID. That method returns a standards-compliant version 4 UUID as a lowercase, hyphenated string, generated from the platform's cryptographically secure random number generator. The tool then applies your formatting choices — converting to uppercase and/or removing hyphens — and lists the results one per line so they are easy to copy into code, a database seed or a spreadsheet.
Anatomy of a v4 UUID
xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx the 4 marks version 4; y is one of 8, 9, a or b (the variant)122 of the 128 bits are random, giving roughly 5.3 × 10³⁶ possible values — collisions are practically impossible.
Notes & assumptions
- Count is clamped to the 1–50 range; out-of-range values snap back to the nearest limit.
- Uppercase and hyphen toggles are cosmetic — the underlying value is unchanged.
- Each Generate click produces fresh, independent UUIDs.
Worked example: seeding a test database
Suppose you are writing a seed script for a Postgres users table whose primary key is a uuid column. Set the count to 25, leave "Include hyphens" checked (Postgres's native uuid type accepts the standard hyphenated form), click Generate UUIDs, then Copy all. Paste the block into your editor and a quick multi-cursor edit turns the 25 lines into INSERT statements or a CSV column. Because each value comes from a secure random source, you can run the script against a shared staging database without worrying that a teammate's seed data collides with yours.
The formatting toggles cover the common variations. An API that expects compact 32-character IDs (some object stores and cache-key schemes) wants "Include hyphens" off; a legacy Windows or .NET system that stores GUIDs in uppercase wants the uppercase toggle on. Either way the underlying 128-bit value is unchanged, so a database that normalizes case treats both spellings as the same key.
UUID versions compared: v1, v4 and v7
The UUID standard defines several versions that differ in where their bits come from. This tool generates version 4, the fully random one, which is the safest default. RFC 9562, published in May 2024, added version 7 for workloads that want time-ordered keys.
| Version | Built from | Sortable by time | Privacy | Use it for |
|---|---|---|---|---|
| v1 | 100-nanosecond timestamp + clock sequence + node ID (historically the MAC address) | Not in string form (time bytes are reordered) | Can leak creation time and the generating machine | Legacy systems that require it |
| v4 | 122 random bits | No | Reveals nothing | General-purpose IDs; the default |
| v7 | 48-bit Unix millisecond timestamp + 74 random bits | Yes, lexically | Leaks creation time only | New database keys where insert order matters |
Collision math for v4: with 122 random bits, the birthday bound puts a 50 percent chance of a single collision at about 2.71 × 10¹⁸ UUIDs (2.7 quintillion), and even a one-in-a-billion chance requires about 103 trillion of them. Generating a billion UUIDs every second, reaching that 50 percent point would take roughly 86 years. This is why production systems insert v4 keys without checking for duplicates.
Where UUIDs are used, and when an auto-increment is better
UUIDs solve one specific problem: minting identifiers on many machines at once without a central counter. That is why they appear as primary keys in distributed databases, as event and request IDs in tracing systems, as idempotency keys on payment APIs (send the same key twice and the charge runs once), as file and object names that never clash in a shared bucket, and as record IDs created offline in mobile apps that sync later.
Against a plain auto-increment integer, the trade-offs are concrete. An integer key is 8 bytes to a UUID's 16, so indexes stay smaller and joins run slightly faster. Sequential integers also insert at the end of a B-tree index, while random v4 keys land on random pages and force more page splits under heavy write load. In the other direction, sequential IDs leak information: /invoice/10452 tells a visitor roughly how many invoices exist and invites probing the neighboring numbers, while a v4 UUID is unguessable. Sequential IDs also cannot be minted by two servers, or by a phone that is offline, without coordination. Version 7 splits the difference, keeping index-friendly ordering while staying collision-safe across machines.
Frequently asked questions
What is a version 4 UUID?
A version 4 UUID is a 128-bit identifier whose bits are almost entirely random, apart from a few fixed bits that mark it as "version 4, variant 1." It is written as 32 hexadecimal digits in five hyphen-separated groups (8-4-4-4-12). Because it is generated from randomness rather than from a machine address or timestamp, it reveals nothing about where or when it was created and can be produced offline.
Are these UUIDs truly unique?
For all practical purposes, yes. A version 4 UUID has 122 random bits, which means about 5.3 × 10³⁶ possible values. You would need to generate billions of UUIDs per second for centuries before a collision became likely. Combined with a secure random source like crypto.randomUUID(), that makes accidental duplicates so improbable that real systems treat v4 UUIDs as unique without checking.
Should I uppercase or remove the hyphens?
That depends on your system. The canonical form is lowercase with hyphens, and most databases and libraries accept that directly. Some legacy systems, URLs or storage keys prefer uppercase or a compact 32-character form with no hyphens. The toggles here let you match whatever your schema expects, but remember the value is the same UUID either way — only its text representation changes.
Can I generate UUIDs for production use?
Yes. crypto.randomUUID() uses a cryptographically secure random number generator, so the values are suitable for database keys, idempotency tokens and distributed identifiers. They are not, however, secret tokens by themselves — a UUID is an identifier, not a password. If you need an unguessable secret, use a dedicated secure-token or password generator with sufficient length.
Are the UUIDs generated on a server?
No. Every UUID is created locally in your browser by the native Web Crypto API, with no network requests at all. The values are never sent to a server, stored or logged, so you can generate as many as you need privately. Reload or close the tab and the generated list is gone — nothing is retained.
What is a UUID v7 and should I use it instead of v4?
Version 7 starts with a 48-bit Unix millisecond timestamp and fills the rest with random bits, so newer IDs sort after older ones as plain strings. That ordering keeps database indexes healthier under heavy inserts than random v4 keys. Choose v7 for new primary keys when your libraries support it, and note the one trade-off: a v7 value reveals when it was created, which v4 does not. Where creation time is irrelevant or sensitive, v4 remains the right call.
Are UUIDs good database primary keys?
They work well when you need keys generated on multiple machines, keys created offline, or keys safe to expose in URLs without inviting enumeration. The costs are 16 bytes of storage per key versus 8 for a bigint and, for random v4 values specifically, scattered index inserts that can slow very write-heavy tables. Many teams keep a bigint internally and expose a UUID as the public ID, or adopt v7 to get both ordering and distributed generation.