ID decoder & generator
Paste an ID to see when it was created and what is inside: UUID, ULID, KSUID, ObjectId or Snowflake.
Generate
Press a buttonCollision odds for random IDs
What is hiding inside an ID?
Many identifiers are not random strings at all: they carry the moment of creation and sometimes the machine that made them. A ULID begins with a 48-bit millisecond timestamp, a UUID v7 does the same, a UUID v1 encodes a timestamp and the MAC address, a KSUID has a timestamp plus 16 random bytes, a MongoDB ObjectId starts with creation time in seconds, and a Snowflake ID packs time, worker and sequence into 64 bits. When you debug a production issue, being able to read the creation time of an ID in a log line is surprisingly useful, for example to see whether a record was created before or after a deployment.
Paste any of these identifiers and the decoder detects the type, shows when it was created and breaks out its fields. For Snowflake IDs pick the epoch of the system that issued the ID (Twitter, Discord, Instagram) or enter a custom one. The tool can also generate ULIDs and NanoIDs, and estimates collision probability for random IDs, which helps when choosing an ID length.
Choosing an ID scheme
- Database primary keys: prefer time-ordered IDs (UUID v7, ULID, Snowflake) over random UUID v4 for insert performance.
- Public identifiers: time-ordered IDs reveal when and how fast you create things; use random IDs where that matters.
- Distributed systems: Snowflake-style IDs need coordinated worker ids and a reliable clock; ULIDs and UUIDs do not.
Decoding is done in your browser with no network access. NanoID and ULID generation uses the browser's secure random generator.
Frequently asked questions
Which ID types can be decoded?
UUID of any version (including the time-ordered v1, v6 and v7), ULID, KSUID, MongoDB ObjectId and Snowflake IDs (Twitter, Discord, Instagram or a custom epoch). The type is detected from the format.
Why use ULID or UUID v7 instead of UUID v4?
Random v4 identifiers insert at random positions in a B-tree index, which causes page splits and cache misses in large tables. Time-ordered IDs (ULID, UUID v7, KSUID, Snowflake) append near the end, which is much friendlier to database indexes and also lets you sort by creation time.
Can the timestamp be trusted?
It is only as good as the clock of the machine that created the ID, and anyone can craft an ID with any timestamp. Use it for debugging and ordering, not for security decisions.
How likely is a NanoID collision?
With the default 64-character alphabet and 21 characters there are about 2^126 combinations. The collision estimate on this page uses the birthday approximation; you would need billions of IDs per second for years to reach a meaningful probability.