Local UUID v4 and UUID v7 generator, validator and export tool
Generate random UUID v4 values, time-ordered UUID v7 values, validate pasted identifiers, normalize formats, inspect version and variant bits, export batches and understand when UUIDs are useful for APIs, databases, logs and distributed systems.
UUIDs are generated locally with browser cryptographic randomness. A UUID is an identifier, not a password, token or authorization secret.
UUIDs solve coordination problems
A UUID is a 128-bit identifier that can be created without asking one central server for the next number. That makes it useful in APIs, event logs, import jobs, client-side drafts, background workers and distributed systems where several services may create records at the same time. UUIDs also avoid exposing simple sequential IDs in public URLs, although they should never be treated as access control by themselves.
This UUID generator supports the two versions most useful in modern web work. UUID v4 is random and widely supported. UUID v7 is time ordered, which can be friendlier for databases and logs because newly generated values sort roughly by creation time. The tool also validates UUIDs, accepts URN, braces and no-hyphen formats, shows version and variant bits, exports batches as newline text, CSV or JSON, and explains collision risk in plain language.
UUID v4 or UUID v7?
Use UUID v4 when you want the safest general-purpose random identifier and your database or application already expects it. Use UUID v7 when sort order matters: event IDs, audit logs, queue records, time-based indexes or systems where recent records are queried often. Both are identifiers, not secrets. A user who knows a UUID should still be checked by authentication and authorization rules before reading or changing a record.
- UUID v4 is random and extremely unlikely to collide when generated correctly.
- UUID v7 starts with a timestamp and then uses randomness, making it easier to sort by time.
- Canonical format is lowercase with hyphens:
8-4-4-4-12hexadecimal groups. - Validation checks syntax, version and RFC variant bits.
- Batch export helps seed tests, fixtures, migration scripts and API examples.
Practical storage and API notes
Store UUIDs consistently. If your database has a native UUID type, use it instead of a plain string when possible. Keep one canonical casing in APIs and logs. For very large tables, test index behavior before switching primary keys. If you need a secret value for password resets, invitations or bearer tokens, generate a real random token with enough entropy and store it with proper expiration; a UUID alone is not the right security design.
Common questions
Can two UUIDs collide?
With correct random generation, UUID v4 collisions are so unlikely that they are not the normal operational concern. Bugs, poor randomness and duplicate imports are more realistic risks.
Is UUID v7 better than UUID v4?
It depends on the job. UUID v7 is attractive for ordered inserts and logs. UUID v4 remains a simple, widely compatible default.
Can I use a UUID as a secret token?
No. A UUID is an identifier. Authorization must come from your application rules, and secret tokens should be generated and stored as secrets.
What is the difference between UUID v4 and v7?
v4 is fully random; v7 is time-ordered with a timestamp prefix, so it sorts chronologically and indexes far better in databases.
Are UUIDs guaranteed to be unique?
Not guaranteed, but a v4 UUID has 122 random bits, making collisions astronomically unlikely. They are safe for practical use.
Should I use a UUID as a database primary key?
It works, but random v4 keys hurt index locality and write performance. Prefer v7, or a sequential primary key with a separate UUID column.
