Numbers

Sortable Short ID Generator

Sortable short IDs combine a base-36 encoded millisecond timestamp with random alphanumeric characters to create compact identifiers that sort chronologically by default. Unlike full UUIDs, which stretch to 36 characters, these IDs stay short enough to embed in URLs, filenames, and user-facing references without looking unwieldy. The timestamp component comes first, so a simple alphabetical sort on any list of these IDs automatically produces chronological order — no separate created_at column needed for basic sequencing. The random suffix appended after the timestamp reduces collision risk between IDs generated in the same millisecond. You control the length of that suffix: a 4-character suffix works fine for low-traffic prototypes, while 8 characters gives comfortable headroom for systems generating hundreds of records per second. Longer suffixes increase uniqueness at the cost of a slightly longer ID string. Adding an optional prefix like usr_, order_, or doc_ namespaces your IDs by entity type. This makes a raw ID instantly recognisable in logs, error messages, and database queries — you can tell at a glance whether you're looking at a user record or a payment record. Prefixes also prevent accidental cross-type lookups when IDs from different tables end up in the same place. This generator lets you produce batches of sortable IDs in one click, which is useful for seeding test databases, pre-allocating identifiers for an import job, or simply exploring what the format looks like at different length settings before wiring it into your codebase.

How to Use

  1. Set the Count field to the number of IDs you need in one batch.
  2. Adjust Random Suffix Length — use 4 for quick tests, 6 or more for production-like output.
  3. Type an optional prefix (e.g. order_, usr_) to namespace IDs by entity type.
  4. Click Generate to produce the full list of sortable IDs.
  5. Copy individual IDs or the entire list and paste them into your database seed file, code, or spreadsheet.

Use Cases

  • •Pre-generating order IDs before a batch database insert
  • •Creating URL slugs that sort newest-first without a query
  • •Namespacing user records with a usr_ prefix in multi-tenant apps
  • •Seeding test fixtures with realistic, time-ordered record IDs
  • •Generating correlation IDs for distributed log tracing
  • •Naming uploaded assets so a directory listing stays chronological
  • •Building short invite codes with a predictable creation sequence
  • •Assigning ticket IDs that customer support can sort by issue age

Tips

  • →Match your prefix to your database table name (e.g. inv_ for invoices) so IDs self-document in logs.
  • →If you plan to index these IDs in a database, keep total length under 16 characters to fit common VARCHAR constraints cleanly.
  • →Generate a batch larger than you need for a seed file — having spare IDs avoids re-running the tool mid-import.
  • →Avoid uppercase letters in your prefix; base-36 output is lowercase, and mixed case breaks lexicographic sort order.
  • →Test sort behaviour by generating two batches a few seconds apart and confirming the earlier batch's IDs alphabetically precede the later ones.

FAQ

How do sortable short IDs sort chronologically?

The timestamp is encoded in base-36 and placed at the start of every ID. Because base-36 digits sort lexicographically in the same order they sort numerically, a plain alphabetical sort on a list of these IDs returns them in the order they were created — no timestamp column required.

Are these IDs unique enough to use as primary keys in a database?

For low-to-moderate traffic systems they work well. The timestamp prefix separates IDs created in different milliseconds, and the random suffix handles same-millisecond collisions. For systems generating thousands of IDs per millisecond, use a dedicated library like ULID or KSUID instead.

What is base-36 encoding and why does it matter?

Base-36 represents numbers using digits 0–9 and lowercase letters a–z. A millisecond timestamp that takes 13 decimal digits shrinks to around 8 base-36 characters. That compression is what keeps the full ID short while still encoding a precise creation time.

How long should the random suffix be?

A 4-character suffix gives 36^4 (about 1.7 million) possible values per millisecond, which is fine for prototypes and low-traffic apps. Use 6–8 characters for production systems where multiple records might be created within the same millisecond.

Can I use these IDs in a URL without percent-encoding?

Yes. The IDs contain only lowercase letters, digits 0–9, and any prefix characters you choose. Stick to letters and underscores in your prefix and the full ID will be URL-safe without any encoding. Avoid special characters like spaces or slashes in the prefix field.

What is the difference between these IDs and a ULID?

A ULID is a standardised 26-character sortable ID with a defined spec and library support across languages. Sortable short IDs are lighter and more customisable — shorter by default, prefix-ready, and easier to read aloud — but lack cross-platform interoperability guarantees that ULIDs provide.

Does the prefix affect sorting?

Yes. If two IDs share the same prefix, they still sort chronologically. But IDs with different prefixes — say doc_ and usr_ — will sort by prefix character first. Keep that in mind if you ever mix prefixed IDs in a single sorted list or indexed column.

Can I regenerate the same ID twice?

Not deterministically. The timestamp is captured at the moment of generation and the suffix is random, so each run produces fresh IDs. If you need reproducible IDs for testing, hardcode them rather than relying on this generator to recreate a specific value.