Skip to main content
Back to Numbers generators

Numbers

UUID v1-Style Generator

Used by developers, writers, and creators worldwide.

A UUID v1-style generator creates time-based identifiers that embed a high-resolution timestamp alongside random node and clock sequence bytes. That timestamp fingerprint means a batch of IDs sorts chronologically — useful when you need to reconstruct event order in distributed systems, audit logs, or append-only tables without storing a separate created_at column. Unlike UUID v4, which is purely random, v1-style IDs carry implicit ordering you can exploit at query time. Each ID follows the standard 8-4-4-4-12 hex format with the version nibble set to 1 and variant bits correctly placed. The node field uses random bytes rather than a real MAC address, so no hardware identity leaks. Generate up to 50 IDs in one click and paste them straight into a seed script, migration file, or test fixture.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  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 clustering keys for time-series data
  • •Generating Kafka message keys that preserve producer-side event ordering across partitions
  • •Populating Jest or Pytest fixtures for services that sort or filter records by UUID v1 timestamp
  • •Creating audit log entry IDs in an append-only Postgres table where chronological traceability matters
  • •Assigning identifiers to distributed transaction spans for chronological reconstruction during incident review

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, so IDs can be sorted chronologically and the creation time can be extracted. UUID v4 is fully random with no time data, which is better when you want no correlation between IDs. Use v1 when insert order matters; use v4 when unpredictability is the priority.

can uuid v1 reveal when a record was created

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

are uuid v1 ids safe to use as primary keys in postgres or mysql

They work, but sequential UUID v1 insertion into a B-tree index can cause page splits because the timestamp bytes are not laid out in ascending byte order. If index fragmentation is a concern, UUID v7 or ULID are byte-sequential alternatives worth considering.