Four ways to generate a unique ID
Every system that mints IDs across more than one machine (or wants IDs that sort by creation time) picks from roughly the same handful of schemes. They trade off differently on size, sortability, and whether they need any coordination between machines to avoid collisions:
| Scheme | Size | Encoding | Sorts by time? | Needs coordination? |
|---|---|---|---|---|
| UUID v4 | 128 bits | hex + dashes, 36 chars | No | No |
| ULID | 128 bits | Crockford base32, 26 chars | Yes (ms) | No |
| Snowflake ID | 63 bits | decimal integer | Yes (ms) | Yes (machine ID) |
| KSUID | 160 bits | base62, 27 chars | Yes (sec) | No |
UUID — coordination-free, but not sortable
A UUID v4 is 128 bits of pure randomness (with a handful of bits fixed to mark its version and variant). No two machines need to agree on anything to generate one without colliding, and nothing about the ID leaks when it was created. The cost: a stream of v4 UUIDs inserted as a database primary key scatters writes across the entire index at random, which hurts insert performance on B-tree indexes far more than a monotonically increasing key would.
ULID — sortable, still coordination-free
A ULID keeps a UUID's 128 bits and coordination-free generation, but spends 48 of those bits on a millisecond timestamp instead of randomness. Encoded in an alphabet whose symbol order matches ASCII order, a ULID sorts correctly as plain text — a useful property a random UUID doesn't have.
Snowflake ID — smallest, but needs a machine ID
A Snowflake ID fits in 63 bits — small enough to be a native 64-bit integer in most languages and databases, rather than a 128-bit value or a string. It packs a millisecond timestamp, a machine ID, and a per-millisecond sequence number. The machine ID is the catch: every generator in the fleet needs a unique one assigned to it, which means some coordination (a config value, a database row, a ZooKeeper-style registry) has to exist somewhere.
KSUID — second-resolution, generous randomness
A KSUID (K-Sortable Unique ID, from Segment.io) packs a 32-bit timestamp — seconds, not milliseconds, since its custom epoch of 2014-05-13 — with 128 bits of randomness, for 160 bits total, base62-encoded to a fixed 27 characters. Base62 (digits + upper + lowercase letters) is more compact per bit than base32 but isn't case-insensitive, so a KSUID can't be safely normalized to one case the way a ULID can. The tradeoff for coarser (second-level) time resolution is a much larger random space per tick than a Snowflake ID gets — no machine coordination needed, and collisions are effectively impossible even with many generators running at once.
What this tool does
Generate & compare mints one ID of each type for the current moment side by side, so the same instant is represented four different ways. Identify an ID takes any ID you paste in, auto-detects which of the four formats it matches (UUID and ULID/KSUID are unambiguous by length and alphabet; a plain digit string is assumed to be a Snowflake ID, which you can decode against a few common epoch presets), and decodes it back into its embedded fields. Everything runs entirely in your browser — nothing is sent anywhere.
FAQ
Which one should I use?
If you don't need sort order, a UUID v4 is simplest and needs zero coordination. If you want IDs that sort by creation time as a database key without assigning machine IDs, a ULID or KSUID both work — ULID is more common and case-insensitive; KSUID trades millisecond precision for a larger random space. If you need the smallest possible ID and can manage machine IDs, a Snowflake ID is the compact option most large platforms (Twitter/X, Discord, Instagram) actually ship.
Can a Snowflake ID be identified with certainty?
No — a Snowflake ID is just an integer, so this tool can only guess based on its magnitude. Decoding one correctly requires knowing which epoch the generator used, which isn't encoded in the ID itself.
Is anything I enter here sent anywhere?
No — generation, identification, and decoding all run entirely in your browser.