Pulling the creation time out of a single ID
When a log line carries an ID but no timestamp column, a Snowflake-style ID still holds the instant it was minted. Enter the ID and the reference epoch to see that instant in UTC and in this device time zone, along with the machine ID and the sequence number.
The bit layout is 1 unused bit, 41 timestamp bits, 10 machine bits and 12 sequence bits, 64 in total. Shifting off the lower 22 bits gives the milliseconds since the epoch; the next 10 bits are the machine and the last 12 are the sequence. You can pick the Twitter (X) epoch of 1288834974657, the Discord epoch of 1420070400000, or type your own. Decoding 1888944671579078978 against the Twitter epoch yields 2025-02-10T13:34:39.256Z, machine 360 and sequence 322.
If the ID is not a Snowflake, numbers still appear but mean nothing. Splitting the machine field into datacenter and worker is the common convention of halving those 10 bits; when a service uses all 10 as one number, read the machine ID only. This page does not mint new IDs. Written as of October 2026.
Frequently asked questions
The reference epoch does not match. A Snowflake carries milliseconds counted from a start instant that each service picks, so the date is only right when you select the epoch that service uses. Enter it manually if you are unsure.
Handling a 64-bit value as a floating point number blurs the last digits beyond roughly nine quadrillion. This page reads the input as a string and computes with BigInt, so every digit survives.
The sequence number increments within a millisecond, so ordering holds inside one machine. With several machines you would be comparing separate sequences, which gives no global ordering guarantee.