Twitter Snowflake Generator

Twitter (X) Snowflake: how tweet IDs work

Every tweet — now post on X — is identified by a numeric Snowflake. The format was open-sourced by Twitter in 2010 (the original repo lives at github.com/twitter-archive/snowflake, archived after the company moved on to a successor called Cinder and then quietly rolled it back). The structure stays the same regardless of branding: a single 64-bit integer with a sign bit, a millisecond timestamp, a datacenter ID, a machine ID, and a per-millisecond sequence.

Bit layout and Twitter epoch

 1 bit  | 41 bits        | 5 bits     | 5 bits  | 12 bits
 sign   | timestamp ms   | datacenter | machine | sequence
 (0)    | since 2010-epoch | (0-31)   | (0-31)  | (0-4095)

The Twitter epoch starts at 1288834974657 ms — that is November 4, 2010 at 01:42:54.657 UTC. To recover the creation time of any tweet you shift the ID right by 22 bits and add the epoch: (snowflake >> 22) + 1288834974657 = unix_ms. Modern tweet IDs are 19 decimal characters because the upper bits keep growing as years pass.

Tweet ID vs status ID, v1.1 vs v2

In the official documentation "tweet ID" and "status ID" mean exactly the same thing — the field is called id in v2 and was historically id_str in v1.1. The v1.1 REST API is deprecated; the current X API v2 returns the ID as a string, not an integer, because 64-bit values overflow JavaScript's native Number (which only safely represents integers up to 2⁵³). Always parse tweet IDs as strings on the client side or you will silently lose precision.

Pre-Snowflake tweets and the X rebrand

Tweets posted between March 2006 and late 2010 used a plain auto-increment integer — those legacy IDs do not decode into a Snowflake timestamp. After the 2023 rebrand from Twitter to X, the ID format was kept untouched: paid blue checkmarks, Community Notes, and the new ranking algorithm all coexist with the same 64-bit Snowflakes. URLs of the form twitter.com/i/web/status/{id} and x.com/{user}/status/{id} resolve to the same object.

Twitter vs Discord Snowflakes

Both platforms use the exact same 64-bit shape but a different epoch. Discord shifted theirs to 1420070400000 (Jan 1 2015) so their IDs start from a smaller numeric range. That means a raw integer alone cannot tell you which service produced it — you need to know the epoch up front to decode the timestamp correctly.

FAQ

Can I extract the date a tweet was posted from just the ID? Yes. Shift right by 22 bits and add the Twitter epoch (1288834974657) to get the unix millisecond timestamp — accurate down to the millisecond. This is the basis of every "first tweet from year X" forensics query.

If a tweet was deleted, can I still see its content using the ID? No. Once deleted, the platform returns a 404 or a tombstone. The only chance is a third-party archive such as the Wayback Machine, archive.today, or a dataset like the Twitter Stream Grab — none guaranteed.

Can a bot or scraper construct fake tweet IDs? Yes — any 64-bit number with a valid past timestamp looks plausible. The platform will simply return 404 for IDs that were never minted. Don't trust an ID until you confirm it returns an actual tweet through the API.

Do retweets and replies have new Snowflakes? Yes. A retweet is a new tweet object with its own ID and timestamp; the original is referenced via referenced_tweets (v2). The same applies to replies and quote tweets.