Generate XID

A 12-byte identifier rendered as 20 lowercase URL-safe characters — 4 bytes of seconds since the Unix epoch, 3 bytes of machine-like random fingerprint, 2 bytes of process-like random ID, and a 3-byte counter.

Browser extensions can read all data on this page. Use a private/incognito window with extensions disabled.

Generated · 0 IDs

Options

Quantity

All zeros, for testing and defaults

This ID

Length 20 chars

Bits 96 (32 timestamp · 24 machine-like · 16 process-like · 24 counter)

Collision risk low

Features

Time-sortable URL-safe

Watch out

Embeds generator fingerprint

Collision

1% collision chance after ≈ 148,663 generators in one second

Random part 40 random bits

Counted together Independent generators in one second

Built-in guard 16,777,216 IDs per second per generator

A single generator stays unique within a second through its 24-bit counter. Separate generators also need their randomized machine and process fields to match, then their counters must line up.

Validate and parse XID

Paste an ID

Paste XID

About XID

Use when: you want an ObjectID-style 12-byte ID encoded as 20 URL-safe characters, with a built-in second-resolution timestamp.

Avoid when: you do not want a stable generator fingerprint inside the ID. This implementation uses random machine-like and process-like fields, shared within a batch and re-randomized on each Regenerate.

How it is generated

An XID is 12 raw bytes (96 bits) encoded as 20 lowercase characters. Same byte layout as a MongoDB ObjectID, but encoded with rs/xid’s base32-hex alphabet instead of hex, which is shorter and URL-safe.

The 12 bytes are the timestamp, then a machine-like fingerprint, then a process-like ID, then a counter. In this browser implementation those identity fields are random and shared within a batch (re-randomized on each Regenerate), so they correlate IDs minted together without exposing a real host or process. Seconds-precision timestamp means same-second IDs only differ in the counter.

Note: the bit packing into characters is rs/xid’s own MSB-first rearrangement, not standard base32 — implementations have to follow the exact mapping or they won’t round-trip.

01 Take the current Unix-seconds time as 4 big-endian bytes for bytes 0–3.
02 Place the 3-byte machine-like fingerprint into bytes 4–6 (from crypto.getRandomValues; shared within a batch, re-randomized on each Regenerate).
03 Place the 2-byte process-like ID into bytes 7–8 (also re-randomized per batch).
04 Place the 3-byte counter into bytes 9–11; start counter at a random 24-bit value and increment by 1 per ID, wrap at 2²⁴.
05 Pack the 96 bits into 20 characters using the rs/xid bit-rearrangement defined in their reference implementation.

Source bytes (12 = 96 bits):

  bytes 0..3    32-bit big-endian Unix-seconds timestamp
  bytes 4..6     3-byte machine-like fingerprint (random per batch)
  bytes 7..8     2-byte process-like ID (random per batch)
  bytes 9..11    3-byte counter (random start, ++ per ID, wraps at 2^24)

Encoded form (20 chars):
  the 12 bytes are packed into 20 output chars using rs/xid's
  custom MSB-first bit rearrangement (not standard base32).
  Each output char carries 5 bits of input.

  example: 9m4e2mr0ui3e8a215n4g

Alphabet (rs/xid base32-hex, lowercase only):
  0123456789abcdefghijklmnopqrstuv

All of this runs in your browser. Random bytes come from crypto.getRandomValues, timestamps come from the system clock, and nothing about the generated ID leaves the tab.