Numbers

UUID v1-Style Generator

UUID v1-style identifiers are time-based unique IDs that embed a timestamp alongside random node and clock sequence values, giving each ID a chronological fingerprint. This makes them fundamentally different from random UUIDs: you can sort v1-style UUIDs to reconstruct the order events occurred, which is invaluable for debugging distributed systems or auditing event streams after the fact. This generator produces properly formatted UUID v1-style strings instantly, with no setup or libraries required. The timestamp baked into each UUID v1 string is derived from the current time at the moment of generation, measured in 100-nanosecond intervals since October 1582. That precision means a batch of IDs generated in quick succession will still sort correctly relative to each other. For applications like Cassandra tables, Apache Kafka message keys, or audit log entries, this temporal ordering is a practical feature rather than just a curiosity. Each generated ID follows the canonical 8-4-4-4-12 hexadecimal format, with the version nibble set to 1 and the variant bits correctly positioned. The node component uses random bytes rather than a real MAC address, preserving the format's uniqueness guarantees without leaking hardware identity. You can generate between 1 and 50 IDs in a single click, ready to paste directly into your code, config file, or database seed script.

How to Use

  1. Set the count field to the number of UUID v1-style IDs you need, between 1 and 50.
  2. Click the generate button to produce a fresh batch of time-stamped UUID v1-style identifiers.
  3. Review the output list and click the copy button to copy all IDs to your clipboard at once.
  4. Paste the IDs directly into your database seed file, code constants, or configuration as needed.

Use Cases

  • •Seeding Cassandra or ScyllaDB tables that use TimeUUID primary keys
  • •Generating Kafka message keys that preserve producer-side event ordering
  • •Creating audit log entry IDs traceable back to an approximate creation time
  • •Populating test fixtures for systems that sort records by UUID v1 timestamp
  • •Assigning identifiers to distributed transactions for chronological tracing
  • •Building event-sourcing systems where insert order must be reconstructable
  • •Generating sortable IDs for append-only ledger or journal tables
  • •Replacing auto-increment IDs in horizontally scaled microservices

Tips

  • →Generate IDs for the same logical batch in one click so their timestamps cluster together and sort as a group.
  • →If you need byte-sequential IDs for SQL B-tree indexes, combine these with a UUID v7 generator instead — v1 is better suited for Cassandra-style clustering.
  • →Extract the embedded timestamp from a v1 UUID by rearranging the three time fields: time_high (positions 15-18) + time_mid (9-12) + time_low (0-7).
  • →When using v1 UUIDs as Kafka keys, records with the same key go to the same partition — pairing time-based keys with a consistent hashing strategy prevents hot partitions.
  • →Avoid using these IDs in public URLs or tokens where the creation timestamp would reveal business-sensitive timing information.

FAQ

What is the difference between UUID v1 and UUID v4?

UUID v1 encodes the current timestamp into the first three fields of the ID, so records can be sorted chronologically. UUID v4 is fully random with no embedded time data, making it better when you want no correlation between IDs. Use v1 when order matters; use v4 when you want maximum unpredictability and no timing information exposed.

Can UUID v1 reveal when my record was created?

Yes. Anyone who knows the UUID v1 spec can extract the embedded timestamp and determine roughly when the ID was generated, down to 100-nanosecond precision. If creation time is sensitive — for example, in public-facing user IDs — consider UUID v4 or a ULID instead.

Does UUID v1 expose my MAC address or machine identity?

Classic RFC 4122 v1 UUIDs do include a MAC address in the node field. This generator substitutes random bytes for the node component, so no hardware identity is leaked while still maintaining the correct format and uniqueness properties.

Are these UUID v1 identifiers globally unique?

The combination of a high-resolution timestamp, a random 14-bit clock sequence, and 48 random node bits makes collisions astronomically unlikely. Generating duplicates in practice is effectively impossible unless you are producing millions of IDs per second on a single machine.

How do I sort UUID v1 strings chronologically?

Standard lexicographic sorting does not work directly because the timestamp fields are split across the UUID in a non-sequential order. You need to rearrange the fields — specifically, move the time_high and time_mid fields before time_low — before sorting. Most UUID libraries offer a getTime() method that extracts the numeric timestamp for correct comparison.

What databases natively support UUID v1 or TimeUUID types?

Apache Cassandra and its derivatives (ScyllaDB, Amazon Keyspaces) have a native TimeUUID type built on UUID v1 and use it for time-series clustering keys. PostgreSQL stores UUIDs as a generic type but lets you sort them with custom functions. MySQL and SQLite treat UUIDs as strings, so timestamp extraction requires application-side parsing.

Can I use these IDs as primary keys in a SQL database?

Yes, but be aware that sequential UUID v1 insertion into a B-tree index (like in PostgreSQL or MySQL InnoDB) can cause page splits and fragmentation because the timestamp moves forward but not in a way that maps to sequential byte order. If index fragmentation is a concern, consider a ULID or UUID v7, which are byte-sequential by timestamp.

How many UUID v1 IDs can this generator produce at once?

You can generate up to 50 IDs in a single batch by setting the count input before clicking generate. Each ID in the batch uses the timestamp at the moment of generation, so IDs produced in the same batch will have very close but not identical timestamps.