UUID GeneratorDeveloper Tools
Generates random v4 and time-ordered v7 UUIDs.
UUID v4 vs v7 for database IDs and public URLs
For UUID v4 vs v7, choose v4 when you want random identifiers without an embedded creation timestamp. Consider v7 when time ordering helps your database design and exposing an approximate creation time is acceptable.
Choose the ID behavior before changing a table
A public URL and a database primary key can use the same identifier, but they have different requirements. A database may benefit from inserting nearby values into an index. A public URL may need to avoid revealing when a record was created. Write those requirements down before selecting a UUID version.
Both versions are 128-bit UUIDs. RFC 9562 defines v4 with 122 random bits after the version and variant bits. Version 7 begins with a 48-bit Unix timestamp in milliseconds. Its remaining fields provide randomness and can include a counter for ordering values generated within one millisecond.
Keep a separate creation-time field if the application needs an explicit event time. An ID's timestamp is not evidence that a business event happened then, and clock adjustments or generator state can affect its relationship to wall-clock time.
UUID v4 vs v7 in a generator and in your database
Use UUID Generator to create sample v4 and v7 values. It generates 1 to 1,000 IDs at a time, with cryptographic randomness supplied by the browser. Keep all the examples lowercase and hyphenated so you compare the same representation.
| Decision | v4 | v7 |
|---|---|---|
| Creation time in the ID | No timestamp field | Timestamp is part of the value |
| Natural time ordering | Random values do not encode creation order | Time prefix supports ordering; same-millisecond behavior depends on the generator |
| Utilza's current implementation | Browser cryptographic random UUID or random bytes | Millisecond timestamp, a 12-bit counter, and random bytes |
| What still needs checking | Uniqueness constraints, column type, access control | The same checks, plus sorting semantics and timestamp exposure |
Utilza's v7 generator increments its counter when several values share a millisecond. If the clock moves backward, that generator keeps its previous timestamp and continues the sequence. This is local state in one generator instance; it does not establish a global event order across browsers or servers.
A deterministic check on October 27, 2026 ran the current generator in Node.js v24.15.0. It supplied three identical millisecond readings, then a later reading and a backward clock reading. The resulting values remained in this order after a normal string sort:
01a17d3b-4a00-7011-9e83-a8cdf2173c61 01a17d3b-4a00-7012-aed3-f81d42678cb1 01a17d3b-4a00-7013-be23-486d92b7dc01 01a17d3b-4a01-7726-b398-bde2072c5176 01a17d3b-4a01-7727-83e8-0d32577ca1c6
The fixture used fixed random input so the sequence can be reproduced. Never reuse these example IDs as new production identifiers. This ordering check measured no database performance.
For a database decision, test the native UUID or binary column type and the actual ordering your database uses. Check insert behavior with your indexes and workload before claiming a speed improvement. If you are changing table definitions or INSERT statements, review the SQL before you run it; formatting a query does not verify its schema or migration safety.
Public IDs also need server-side authorization. Knowing an identifier must not give a caller access to another user's record. The distinction between reading a value and trusting it is also covered in our guide to decoding and verifying a JWT.
Choose a UUID version for a database key or public URL
- Write down whether the ID will appear in public URLs, whether creation time is sensitive, and whether records are generated on more than one server.
- Choose v4 for samples when a timestamp is unnecessary or its exposure is unwanted. Choose v7 for samples when time ordering is useful and timestamp exposure is acceptable.
- Generate a small batch in UUID Generator with lowercase and hyphens enabled. Compare the generated sequence with a sorted copy.
- Repeat the comparison in the database column type and collation your application actually uses. Treat values from separate generators as separate sequences.
- Test the intended insert workload and indexes if performance is part of the decision. Retain a uniqueness constraint and check the application's authorization rules.
- Keep event timestamps in their own fields. Review any change to existing keys, references, and URL handling before deploying it.
What choosing v7 will not guarantee
- No database throughput, latency, storage-size, or index-size improvement was measured for this guide. A time-ordered format alone does not provide a benchmark result.
- A v7 timestamp can reveal approximate generation time. Using v4 avoids that timestamp field, but does not by itself make a URL private.
- Ordering within one generator does not prove ordering across distributed clocks, concurrent processes, or separate browser tabs.
- A UUID is an identifier. It does not replace authentication, authorization, or a dedicated secret token.
- Uniqueness is a design goal, not a reason to remove a database uniqueness constraint or skip handling an insert conflict.
- The browser tool offers v4 and v7 only. It does not migrate existing database keys or generate name-based UUIDs.
Frequently asked questions
Should I use UUID v4 or v7 as a database primary key?
Use your storage and privacy requirements to decide. V7 offers a time-ordered prefix; v4 has no timestamp field. Test the actual column type, indexes, and workload before making performance claims.
Does UUID v7 expose when a record was created?
It contains a Unix-millisecond timestamp from the generator. That can reveal approximate generation time, but it is not an authoritative record of a business event.
Do UUID v7 values always sort in creation order?
V7 has a time prefix, but ordering within one millisecond depends on the implementation. Utilza maintains a counter within one generator; it does not coordinate separate browsers or servers.
Is a UUID safe to use as the only protection for a URL?
No. An identifier does not authorize access. Check permissions on the server for every protected record, regardless of whether its URL uses v4 or v7.
Related tools
Tools used in this guide