NanoID, ULID & Snowflake ID Generator
Every popular ID format in bulk — and the creation time inside the ones you already have.
Generate IDs
Decode IDs
ULIDs, MongoDB ObjectIds, KSUIDs and Snowflakes are recognised automatically. NanoIDs and CUID2s are random and contain nothing to decode.
| Line | ID | Format | Created | Details |
|---|
About the NanoID, ULID & Snowflake ID Generator
Create identifiers in the formats modern apps use instead of — or next to — UUIDs: NanoID (short, URL-safe, any alphabet), ULID (sortable, with a millisecond timestamp), CUID2 (hashed, reveals nothing), KSUID (sortable, 128 random bits), MongoDB ObjectId and Snowflake IDs in the Twitter/X, Discord or a custom-epoch layout. Make one or up to a million at a time (100,000 for CUID2), then copy them or download them as a text or CSV file.
The Decode IDs box works the other way round: paste ULIDs, ObjectIds, KSUIDs or Snowflakes (mixed, one per line) and it shows when each one was created plus its other fields — handy for finding out when a Discord account or message was created, or when a database row was inserted. Everything runs in your browser with its cryptographically secure random number generator.
How to use it
- Choose the ID format. Each format’s options appear below it: alphabet and length for NanoID, monotonic mode for ULID, machine fields and epoch for Snowflakes.
- For time-based formats, keep Now or pick A specific time — for example to build a Snowflake cursor for an API that pages by ID.
- Set How many (up to 1,000,000; 100,000 for CUID2) and press Generate. Use Copy, Download .txt or Download .csv — the CSV adds each ID’s embedded creation time. Batches over 10,000 show their first 10,000 IDs on the page; the downloads contain every one.
- To read an ID, paste it into Decode IDs. The format is detected automatically; for Snowflakes choose which service they come from, because each uses its own epoch.
Examples
175928847299117063
Created 30 Apr 2016, 11:18:25.796 UTC · internal worker ID 1 · internal process ID 0 · increment 7
Discord IDs are (milliseconds since 2015-01-01) << 22, plus the worker, process and increment fields.
01ARYZ6S41TSV4RRFFQ69G5FAV
Created 30 Jul 2016, 22:36:16 UTC (Unix 1469918176385 ms)
The first 10 characters are the timestamp, so ULIDs sort by creation time.
507f1f77bcf86cd799439011
Created 17 Oct 2012, 21:13:27 UTC · counter 4,427,793
Default alphabet (64 characters), length 21, 1,000 IDs per hour
126 bits of randomness — about 149 billion years until a 1% chance of one duplicate
Common uses
- Short public IDs for URLs, invite links and file names (NanoID).
- Primary keys that sort by insertion time, keeping database indexes compact (ULID, KSUID).
- IDs that must not leak creation time or volume to users (CUID2, NanoID).
- Test data and fixtures in the exact format a MongoDB or Discord integration expects.
- Working out when a Discord user, server or message, a tweet, or a MongoDB document was created.
Which format should I use?
- NanoID — the shortest random IDs for a given safety margin; pick the alphabet and length, and the page shows the collision risk.
- ULID — 128 bits like a UUID (it can be stored in a UUID column), but sortable: a 48-bit millisecond time plus 80 random bits. In monotonic mode, IDs made in the same millisecond still increase, as the ULID specification describes.
- KSUID — sortable to the second, with 128 random bits after the time.
- CUID2 — a random letter followed by a SHA3-512 hash of the time, a random salt, a counter and a device fingerprint; it reveals nothing about when it was made.
- ObjectId — only if you work with MongoDB: 4 bytes of seconds, a 5-byte value fixed for the process and a 3-byte counter.
- Snowflake — 64-bit integers for systems that want numeric, time-ordered IDs; real deployments assign every server its own machine fields so IDs cannot collide.
Snowflake layouts and epochs
A Snowflake is a 64-bit integer: the top 42 bits count milliseconds since an epoch, then come two 5-bit machine fields and a 12-bit sequence that counts IDs within one millisecond (timestamp << 22 | field1 << 17 | field2 << 12 | sequence). Twitter’s original IdWorker uses the epoch 1288834974657 (4 Nov 2010, 01:42:54.657 UTC) with a datacenter ID and a worker ID; Discord uses 1420070400000 (1 Jan 2015) with an internal worker and process ID. Other services (Instagram, Mastodon and many in-house systems) use a different epoch or a different bit split, so choose Custom epoch for those and check the layout in their documentation.
Discord’s API documentation notes that because Snowflakes are just numbers with a timestamp, you can generate one for any moment and use it as the before or after value when paging: choose A specific time, machine fields 0 and one ID.
Limitations
- Up to 1,000,000 IDs per batch (100,000 for CUID2, which hashes every ID with SHA3-512). Copy works up to 100,000 IDs; the downloads always contain the whole batch. ULIDs, ObjectId counters and Snowflake sequences continue across batches.
- A Snowflake sequence holds 4,096 IDs per millisecond. Bigger batches move on to the following milliseconds, as Twitter’s IdWorker does, so their last IDs carry slightly later times.
- NanoIDs and CUID2s are random, so the decoder can only tell you that they contain no timestamp.
- Snowflakes from different services cannot be told apart by their digits — the decoder uses the service (epoch) you select.
- IDs made here are unique with overwhelming probability, but Snowflakes and ObjectIds generated on several machines are only collision-free when each machine has its own fields — real systems coordinate that; this page cannot.
Privacy
Everything happens in your browser. What you enter or open here is not uploaded or stored by MySmartCoPilot.
Frequently asked questions
How do I find out when a Discord account or message was created?
Copy its ID (in Discord, switch on Developer Mode in the Advanced settings; the menus then offer “Copy ID”), paste it into Decode IDs and keep “Snowflake numbers are from” set to Discord. The created time is shown in UTC and in your local time.
Is a NanoID as unique as a UUID?
With the default alphabet of 64 characters and 21 characters it has 126 random bits, slightly more than the 122 of a UUID v4. Shorter IDs or smaller alphabets have fewer — the estimate under the options shows how many IDs you can create before a duplicate becomes a realistic risk.
Are these IDs generated securely?
Yes: all random parts come from your browser’s cryptographically secure generator (crypto.getRandomValues), and NanoID characters are chosen without modulo bias. Nothing is sent to a server. Still, IDs are identifiers — use the Password Generator for secrets and API keys.
Why do all my ObjectIds have the same middle part?
That is how the ObjectId specification works: the 5 bytes after the timestamp are random once per process (here: once per page visit), and the last 3 bytes are a counter that increases by one for every ID. Reload the page for a new process value.
Can I store a ULID in a UUID column?
Yes. A ULID is 128 bits, so it fits a UUID type exactly; the decoder shows the UUID form of each ULID. It will not be a valid RFC 9562 UUID version, but databases such as PostgreSQL store and sort the bytes all the same.