Snowflake ID Decoder

Large web services need unique IDs that are made in many places without coordination. One answer, which Twitter published in 2010 and others have copied, is the Snowflake ID: a 64-bit number whose high bits are a timestamp. Because the time comes first, IDs sort by creation time, and because the lower bits identify the machine and a counter, thousands of servers can issue them at once without a clash. If you hold such an ID, you can read when and where it was made.

The layout

The number is split into fields. The top 41 bits count milliseconds since an epoch chosen by the platform. Below that are bits for the machine that generated the ID and a sequence number that increases when several IDs are made in the same millisecond. Twitter and Discord both use five bits for each of two machine fields and twelve for the sequence, written as 41 + 5 + 5 + 12 plus an unused top bit. Instagram uses a different split, 41 bits of time, 13 bits for the shard and 10 for the sequence.

Different epochs

The same number decodes to different dates in different systems, because each platform started counting at its own moment. Twitter’s epoch is 1288834974657 in Unix milliseconds, which is 4 November 2010. Discord’s is 1420070400000, the start of 2015. Instagram’s is 1314220021721, in August 2011. Choose the platform before pasting, and the date, the machine fields and the sequence all follow from that choice.

Using the page

Pick Twitter or X, Discord or Instagram, paste IDs one per line, and read the table: the ID, the creation time in UTC to the millisecond, and the fields for that layout. An ID that is not a whole number of at most 20 digits, or that exceeds 64 bits, is reported. Below the table you can build an ID: enter a date and the field values, and the page shows the resulting number and a button to send it to the decoder.

Why BigInt matters

A 64-bit ID needs more precision than a JavaScript number provides. Reading 1541815603606036480 as a number gives the right order of magnitude but changes the last digits, which are exactly where the sequence and worker are stored. The decoder takes the digits as a big integer and shifts and masks them exactly, so the fields are correct for any valid ID.

A worked example

The Twitter sample 1541815603606036480 decodes to 2022-06-28 16:07:40.105 UTC, datacenter 11, machine 26 and sequence 0. The second sample, 1204889173891276800, is from 2019-12-11 22:22:19.471 UTC, with machine 14. For Discord, the ID 175928847299117063 from the platform’s own documentation decodes to 2016-04-30 11:18:25.796 UTC, worker 1, process 0 and increment 7.

Limits

Only the three layouts listed are included, and a platform may change its scheme. The date is when the ID was generated, which is normally when the object was created, but IDs for imported or edited content can differ. The machine fields identify infrastructure, not a person, and mean nothing outside the platform. The page does not call any API, so it cannot tell whether an ID is still valid or what it points to.

Related tools

• Timestamp Converter converts the milliseconds in the result to other formats.
• ULID Generator produces another time-sortable identifier.
• ObjectId Decoder reads MongoDB ids, which also hold a timestamp.
• UUID Generator makes ids that do not carry a time.