Recover creation time, worker ID and sequence from Discord and X (Twitter) Snowflake IDs. Reverse lookup by timestamp and custom epochs supported
Uses the service (epoch) and shift width selected above. You get the lowest and highest ID that can be issued within that single millisecond, which is handy when writing a query such as "only IDs created after this moment".
A Snowflake ID is a 64-bit integer. In the common layout the top 42 bits hold milliseconds elapsed since the epoch, the next 5 bits are the worker ID, the following 5 bits are the process ID, and the low 12 bits are a per-millisecond counter. So id >> 22 yields the elapsed milliseconds, and adding the epoch gives Unix time. That leaves room for up to 4096 IDs in the same millisecond.
The epoch is the moment a service treats as zero milliseconds. Discord uses 2015-01-01 00:00:00 UTC (1420070400000 in Unix milliseconds); X (formerly Twitter) uses 1288834974657. Pick the wrong one and every decoded date is off by years. If a result looks implausible, check this first.
Worker ID, process ID and sequence are only broken out when the shift width is 22 bits. With any other shift the low-bit allocation differs per service, so the tool does not guess. It shows the combined low-bit value instead.
A unique identifier built as a 64-bit integer. Its high bits hold the number of milliseconds elapsed since a service-defined reference time, so the creation date can be recovered from the ID itself. Discord and X (formerly Twitter) use this scheme.
The reference time a service treats as zero milliseconds. Discord uses 2015-01-01 00:00:00 UTC (1420070400000); X (formerly Twitter) uses 1288834974657. Using the wrong epoch shifts every decoded date.
No. All arithmetic runs in your browser with JavaScript BigInt, and the ID is never sent to a server.