UUID Generator (v4 + v7)
Random or time-ordered UUIDs. Pick a count, click generate. Local crypto only.
What this tool does
Generates universally unique identifiers (UUIDs) in two common variants. Version 4 is fully random: 122 bits of entropy from the browser's cryptographic random number generator, formatted as the familiar 8-4-4-4-12 hex string. Version 7 is time-ordered: the first 48 bits are the current Unix timestamp in milliseconds, followed by 74 bits of randomness. Both variants comply with RFC 9562 (the modern UUID spec). Generation is local; no UUIDs are sent off your machine.
How to use it
Pick a version, pick a count, click Generate. UUIDs print one per
line in the output box. Use Copy all to copy the whole list at once.
Example v4 output: 3f29c8e1-4d11-4a3b-9f7c-2e8a4b3c1d56. Example v7
output: 0190d4a2-3f8c-7b1e-8a23-4c5d6e7f8901 (the leading hex digits
encode the timestamp, so v7 UUIDs from the same minute sort together).
Common use cases
- Generating primary keys for new database rows when you want client-side id assignment.
- Creating idempotency keys for HTTP requests or queue messages.
- Producing unique filenames for upload destinations without server round-trips.
- Mocking up records in tests, design comps, or sample data.
- Tracing-id or request-id values in logs.
Common pitfalls
- v4 is unsorted. Two v4 UUIDs generated milliseconds apart sort in random order. If your database benefits from clustered inserts (most do), v7 is the better choice. If you store UUIDs as binary, v7 also gives you cheap range scans by time.
- UUIDs are not secrets. They are not designed to be unguessable access tokens, even though v4 has cryptographic entropy. Treat them as identifiers, not credentials.
- v1 and v3 and v5 exist too. v1 leaks the MAC address of the generator and a high-precision timestamp; rarely the right choice today. v3 and v5 are derived from a namespace + a name (one is MD5, one is SHA-1), useful for creating deterministic IDs from inputs but not what most people want when they ask for "a UUID."
Frequently asked questions
- What is a UUID and what is it used for?
- A Universally Unique Identifier is a 128-bit value formatted as 8-4-4-4-12 hex characters. UUIDs are designed so two systems can independently generate identifiers that are extremely unlikely to collide, which makes them useful for primary keys assigned client-side, idempotency keys for HTTP requests, request-id values in logs, content-addressable filenames, and similar cases where coordinated id assignment is impractical.
- What is the difference between UUID v4 and UUID v7?
- v4 is fully random: 122 bits of entropy from a cryptographic random number generator. The order of two v4 UUIDs generated milliseconds apart is unpredictable. v7 starts with a 48-bit timestamp (Unix milliseconds) followed by random bits. v7 UUIDs from the same minute sort together, which means they cluster nicely in B-tree indexes and enable cheap range scans by time. Both follow RFC 9562.
- When should I use v7 instead of v4?
- Use v7 when the UUID will be used as a database primary key, when you want IDs to roughly sort by creation time, or when you store UUIDs as binary in indexed columns. v4 is fine for ad-hoc identifiers, idempotency keys, and cases where ordering does not matter. The randomness in v7 is still cryptographic; you do not give up unguessability by switching.
- Are UUIDs safe to use as access tokens or session keys?
- No. UUIDs are designed to be unique, not unguessable in the cryptographic sense. v4 has cryptographic entropy but is not designed to resist a determined attacker. For access tokens, use a purpose-built primitive: a random byte string from a CSPRNG with at least 128 bits of entropy, encoded as base64url, with appropriate expiry and revocation handling.
- What about UUID v1, v3, and v5?
- v1 includes the generator MAC address and a high-precision timestamp; rarely the right choice today because it leaks identifiers. v3 and v5 are derived from a namespace plus a name (v3 uses MD5; v5 uses SHA-1) and are useful when you want the same input to always produce the same UUID, such as content-addressable IDs. Most modern usage is v4 or v7.
- How likely is a UUID collision in practice?
- For v4 specifically, generating one billion UUIDs per second for 85 years gives roughly a 50 percent chance of a single collision somewhere. For practical purposes, treat collision risk as zero. For v7, collisions become more likely if you generate millions of UUIDs in the same millisecond, but for typical workloads (a few thousand per second) the risk is still negligible.
Cite this tool
For academic, journalistic, or technical references. Pick a format:
Citations use 2026 as the publication year. Access date is left as a fillable placeholder where the citation style expects one.