Generate UUID v4 and v7 identifiers in bulk
Random v4 UUIDs for anything that just needs uniqueness, time-ordered v7 UUIDs for database primary keys where insert locality matters. Both are generated in the browser with crypto-grade randomness.
- Versions
- v4 random, v7 time-ordered
- Bulk
- Up to 10,000
- Randomness
- crypto.getRandomValues
How to use it
- Choose the version v4 is fully random and the safe default. v7 embeds a millisecond timestamp in the leading bits, which keeps indexes compact in an ordered database.
- Set the count and the format Generate between one and ten thousand identifiers at once, and choose whether to output them in the standard hyphenated form, uppercase, wrapped in braces or without hyphens.
- Copy the list One click copies every generated identifier, newline separated, ready to paste into a seed script or a fixture file.
Questions people ask
What is the difference between UUID v4 and v7?
v4 is entirely random. v7 puts a 48-bit millisecond timestamp in the first six bytes and fills the rest with random bits, so ids are sortable by creation time while remaining just as collision-resistant.
Are these identifiers cryptographically random?
Yes. They come from the browser’s crypto.getRandomValues, which is a CSPRNG. Math.random is never used.
Can I use these as database primary keys?
Yes, and v7 is the better choice for a distributed or high-write system because inserts stay sequential in the index. If you are using v4, consider a native sequential type instead unless you specifically need globally unique ids across systems.
What are the nil UUID and the max UUID?
The nil UUID is all zeroes and the max UUID is all ones. Both are reserved; the nil UUID conventionally means "no value" and is used to indicate an unset field.
Do generated identifiers differ between page loads?
Yes, every generation call produces new values. Nothing is cached, stored or sent to a server.
Should I use a UUID or an auto-incrementing integer?
Use an integer when a single database owns the data and you want the smallest possible index. Use a v7 UUID when ids must be created in more than one place, merged across systems, or exposed in an API where leaking row counts is a concern.
Reference
The same identifier in different notations
| Format | Value |
|---|---|
| Standard | `3f2b9c14-7a5e-4d8b-9c02-1e6a7b3d5f90` |
| Uppercase | `3F2B9C14-7A5E-4D8B-9C02-1E6A7B3D5F90` |
| No hyphens | `3f2b9c147a5e4d8b9c021e6a7b3d5f90` |
| Braced | `{3f2b9c14-7a5e-4d8b-9c02-1e6a7b3d5f90}` |
Details that catch people out
A v4 UUID starts with random bits, so consecutive inserts land in random parts of the index. A v7 UUID starts with a 48-bit millisecond timestamp, so ids sort by creation time and inserts stay at the end of the index. The random 74 bits are still there afterwards, so the collision probability is unchanged.
A v4 UUID has 122 random bits, which is enough that guessing is hopeless, but the identifiers are routinely logged, put in URLs and returned in API responses. Treat a UUID as a public identifier, not a token, and use a proper credential for anything that grants access.
Guides that go deeper
- UUIDs, ULIDs and Snowflake IDs 9 min read · How to choose an identifier: random UUIDv4, time-ordered UUIDv7, ULID, Snowflake and…
Last reviewed 2026-10-05. Every tool on DevSnap runs entirely in your browser, so whatever you paste here never reaches a server.