Snowflake ID Decoder
Extract the timestamp from Discord, Twitter/X, or Instagram Snowflake IDs.
Snowflake ID
The Snowflake decoder extracts the embedded creation timestamp from Discord, Twitter/X, or Instagram Snowflake IDs. Pick the platform, paste the ID, and the decoder returns the creation date plus the internal worker, process, and sequence numbers that were packed into the same integer. Snowflake IDs look identical across platforms (a long number) but use different epoch start dates, so the platform switcher is essential for an accurate decode.
What a Snowflake ID Actually Contains
A Snowflake is a 64-bit integer that packs four pieces of information into one number: a timestamp, a worker ID, a process ID, and a sequence counter. The format was invented at Twitter and adopted (with small variations) by Discord, Instagram, and several other large platforms. Splitting the integer into its parts gives you the moment the ID was generated, plus enough metadata to reason about which server generated it.
- Timestamp (top bits): the number of milliseconds since the platform's epoch. Each platform picked a different start date, which is why the decoder needs to know the platform.
- Worker ID (5 bits, Discord/Twitter): identifies the machine that generated the ID, allowing the system to scale horizontally without coordination.
- Process ID (5 bits, Discord/Twitter): identifies the process within a machine, for systems running multiple ID generators per host.
- Sequence (12 bits, Discord/Twitter): a counter that increments for each ID generated within the same millisecond, preventing collisions in bursts.
Instagram uses a slightly different bit layout (no separate worker/process fields, more bits for the sequence), so the decoder applies the right split based on the platform you select.
Platform-Specific Epochs
Each platform chose its own epoch (the moment Snowflake counts from), so the same numeric ID would decode to wildly different dates without picking the right one:
- Discord: January 1, 2015 (timestamp 1420070400000 ms). Discord-launched IDs are obvious because they decode to a date sometime in or after 2015.
- Twitter/X: November 4, 2010 at 01:42:54.657 UTC (timestamp 1288834974657 ms). Twitter's epoch is the moment Snowflake itself went live in production.
- Instagram: January 1, 2011 (timestamp 1293840000000 ms). Instagram adopted the format in 2014 but retroactively used 2011 as the epoch.
If you decode a Discord ID with the Twitter epoch, you get a date around 2014; if you decode a Twitter ID with the Discord epoch, you get a date around 2020. Always select the matching platform before pasting the ID, or you will misread the creation date.
When to Decode a Snowflake
The most common reason to decode a Snowflake is reconstructing a timeline from IDs alone, without access to a database:
- Moderation forensics: a Discord channel or user ID decodes to the exact moment that channel was created or that account joined. Useful for distinguishing legitimate users from accounts created moments before a raid.
- Bot debugging: Discord message IDs in error logs contain the moment the message was sent, often before the timestamp field was even populated.
- API rate-limit reasoning: the sequence counter shows how many IDs the server generated in the same millisecond, which can reveal load patterns.
- Sorting without timestamps: Snowflake IDs sort chronologically because the timestamp is in the top bits. You can order a list by ID alone and get the creation order for free.
- Cross-platform investigations: when content is reposted from Twitter to Discord, decoding both IDs places the events on a single timeline.
For other ID formats that embed a creation timestamp, see the UUID decoder (UUID v1, v6, v7), the ULID decoder, and the MongoDB ObjectId decoder. For decoding a JWT access token instead, use the JWT decoder.
Why Snowflake Works So Well
Snowflake solved a real distributed-systems problem: how do you generate unique IDs at scale without a central coordinator? Auto-incrementing database IDs require all writes to go through a single source of truth. UUIDs are unique but unsortable (v4) or leak the MAC address (v1). Snowflake gives unique, sortable, time-ordered, 64-bit IDs with no coordination and no PII leakage.
The trade-off is that the format depends on every server having a roughly synchronized clock. If one Snowflake generator's clock drifts backward by a few seconds, it might issue IDs that collide with future IDs from a server with a correct clock. Production deployments handle this with strict NTP synchronization and per-generator clock-skew detection.
Frequently Asked Questions
A Snowflake is a 64-bit integer ID that packs a creation timestamp, a worker/machine ID, a process ID, and a sequence counter into one number. The format was invented at Twitter for distributed ID generation at scale and is now used by Discord, Instagram, and many other platforms. The top bits contain the timestamp, so IDs sort chronologically by default.
Each platform uses a different epoch (start date) for its Snowflake counter. Discord starts from January 1, 2015. Twitter/X starts from November 4, 2010. Instagram starts from January 1, 2011. The same ID decodes to a different date depending on which epoch you subtract, so the decoder needs to know the platform before it can produce an accurate timestamp.
Enable Developer Mode in Discord (User Settings -> Advanced -> Developer Mode), then right-click any user, channel, or message and pick Copy ID. Paste the resulting 17-19 digit integer into the decoder with Discord selected as the platform. The result includes the exact creation timestamp, useful for distinguishing established accounts from brand-new ones during moderation.
The worker ID (5 bits) identifies which machine in the cluster generated the ID. The process ID (5 bits) identifies which process on that machine generated it. Together they let the platform run up to 1024 independent ID generators in parallel without coordination, since each generator has a unique (worker, process) pair. These fields are mostly useful for internal load analysis and not part of the public-facing API.
The sequence is a counter that increments for each ID generated within the same millisecond by the same worker/process. It prevents collisions when a single generator issues many IDs in a burst. A high sequence number (close to 4095 for Discord/Twitter) indicates the generator was running near its per-millisecond limit at that moment, useful for detecting load spikes.
Yes. The timestamp occupies the top bits of the Snowflake, so sorting by the integer value automatically sorts by creation time. This makes Snowflakes ideal for time-ordered lists and pagination without an extra timestamp column. Two IDs generated in the same millisecond on different generators are not strictly ordered by clock time but are still totally ordered by integer value.
Instagram uses 41 bits for the timestamp and 23 bits for a shard/sequence combination, rather than the Discord/Twitter split of timestamp + worker + process + sequence. Instagram only runs the ID generator inside the database itself (one generator per shard), so it does not need worker/process fields. The decoder applies the right layout when you select Instagram as the platform.
Partially. A real Snowflake decodes to a plausible date (after the platform's epoch but not in the far future) and has a reasonable worker/process/sequence layout. A random 19-digit number will usually decode to an absurd date or impossible bit pattern. For absolute certainty, query the platform's API with the ID and see if it returns a real resource.
The 41-bit timestamp field holds about 69 years' worth of milliseconds. Discord (epoch 2015) runs out around 2084. Twitter/X (epoch 2010) runs out around 2079. Instagram (epoch 2011) runs out around 2080. By those dates the platforms will either have migrated to a different ID format or extended the timestamp into one of the unused bits, since 64 bits in total is the hard limit.
Because the epoch is different on each platform. Discord subtracts 2015 from the timestamp, Twitter subtracts 2010, Instagram subtracts 2011. Decoding a Discord ID with the Twitter epoch gives a date roughly five years too late. Always confirm which platform issued the ID before decoding, ideally from context (the URL or app you copied it from).