Skip to main content
Back to Numbers generators

Numbers

Timestamp-Based ID Generator

Used by developers, writers, and creators worldwide.

A timestamp-based ID generator builds sortable unique identifiers by combining a Unix millisecond timestamp with a random character suffix. Unlike UUIDs, these IDs encode creation time directly in the identifier, so records sort chronologically without a separate created_at column. That makes them practical for database primary keys, event logs, and file naming schemes where insertion order matters. You control suffix length (default 6 characters), casing (uppercase or lowercase), and one of four separator formats — including no separator at all for compact strings. Produce up to hundreds of IDs in one batch, ready to paste into seed scripts, config files, or API mocks.

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 how many timestamp IDs you need in one batch.
  2. Adjust Random Suffix Length — use 6 for casual projects, 10+ for distributed or high-volume systems.
  3. Choose a Format from the dropdown to set how the timestamp and random parts are joined.
  4. Select Uppercase or Lowercase for the random suffix to match your project's naming convention.
  5. Click Generate, then copy individual IDs or select all output to paste into your code or database.

Use Cases

  • •Seeding a MongoDB staging collection with sortable _id values that reflect realistic insertion order
  • •Naming S3 or GCS upload objects so buckets sort chronologically without a metadata query
  • •Generating order IDs for an e-commerce checkout that encode approximate purchase time in the key
  • •Creating request trace IDs for distributed microservices logs that collate naturally in Kibana or Datadog
  • •Labelling versioned deployment artifacts or config snapshots so CI pipelines sort them without extra tooling

Tips

  • →If two IDs generated in the same millisecond must stay ordered, increase suffix length rather than relying on timestamp alone.
  • →Pair lowercase IDs with a hyphen separator when storing as URL slugs — they stay readable and require no encoding.
  • →Generate a batch of 50-100 IDs in advance and store them as a pool; this avoids timestamp collisions in burst-write scenarios.
  • →The 13-digit millisecond timestamp prefix will remain valid and sortable until the year 2286, so no truncation concerns for modern projects.
  • →When using these as file names, sort lexicographically (ASCII order) rather than numerically — the timestamp prefix makes both methods equivalent.
  • →For audit logs, store the full ID including timestamp prefix rather than converting it; the ID itself becomes a lightweight creation-time record.

FAQ

why use timestamp ids instead of uuids for database primary keys

UUIDs are random, so inserts scatter across a B-tree index and fragment it over time, slowing range queries. Timestamp IDs always append near the end of the index, keeping inserts fast and making 'all records after time X' queries trivial. They also double as a rough audit trail without an extra column.

are timestamp-based ids unique enough for production use

They are not cryptographically guaranteed, but collisions are extremely unlikely. A 6-character alphanumeric suffix gives roughly 56 billion combinations per millisecond. For high-throughput or distributed systems, bump the suffix length to 10–12 characters — 12 characters yields over 3 trillion combinations per millisecond.

how is this different from ULID or KSUID

ULID and KSUID are standardised specs with fixed lengths and defined bit layouts, useful when cross-team interoperability matters. This generator lets you tune suffix length, separator style, and casing to fit your own conventions. Use the standards when you need a published spec; use this when you need something readable and immediately customisable.