Introduction
When you see a long integer like `175928847299117063` in a Discord log or a Twitter API response, that number is not random. It is a Snowflake ID: a 64-bit value that encodes a millisecond timestamp, a datacenter ID, a worker ID, and a sequence number, all packed into a single integer. Decoding it tells you exactly when the object was created and which machine generated it. This Snowflake ID decoder supports Twitter/X, Discord, and Instagram epochs, and shows the full 64-bit binary breakdown. Paste an ID above and the decoded fields appear instantly. Nothing is sent to a server.
What this tool does
- Decodes any 64-bit Snowflake ID into its four components: 41-bit millisecond timestamp, 5-bit datacenter ID, 5-bit worker ID, and 12-bit sequence number.
- Supports built-in platform epochs: Twitter/X (1288834974657, 2010-11-04), Discord (1420070400000, 2015-01-01), and Instagram (1314220021721, 2011-08-25).
- Accepts a custom epoch in milliseconds for systems that use their own Snowflake variant with a different start date.
- Displays the decoded timestamp as both Unix milliseconds and an ISO 8601 date, so you can see the exact creation time of the object.
- Shows the full 64-bit binary representation with a color-coded bit field breakdown separating the timestamp, datacenter, worker, and sequence regions.
- Uses BigInt arithmetic to handle the full 64-bit range without floating-point precision loss, which matters because JavaScript Number loses integer precision above 2^53.
How this tool works
Select the platform (Twitter/X, Discord, Instagram, or Custom) from the dropdown. If you select Custom, enter the epoch in milliseconds. Paste a numeric Snowflake ID into the input field.
The tool converts the input string to a BigInt and masks out each bit field. The bottom 12 bits (bits 0-11) are the sequence number. The next 5 bits (bits 12-16) are the worker ID. The next 5 bits (bits 17-21) are the datacenter ID. The top 41 bits (bits 22-62) are the millisecond timestamp, to which the platform epoch is added to produce the absolute Unix timestamp. Bit 63 is the sign bit and is always 0 for valid Snowflake IDs.
The tool displays the decoded timestamp as both Unix milliseconds and an ISO date string. It also shows the full 64-bit binary representation, split into four labeled sections: timestamp (41 bits), datacenter (5 bits), worker (5 bits), and sequence (12 bits). A visual bar in the settings panel color-codes each field so you can see the bit layout at a glance.
If the input is not a valid non-negative integer, the tool reports an error. The tool does not validate that the ID was actually generated by the selected platform, so you can decode a Discord ID with the Twitter epoch to see what happens (the timestamp will be wrong by the difference between the two epochs).
How Snowflake ID decoding works
Snowflake is a 64-bit ID format designed by Twitter engineers and open-sourced in 2010. Twitter needed unique IDs for tweets that could be generated across hundreds of servers without a central coordinator, and that were roughly sortable by creation time. The 64-bit layout packs a timestamp, machine identifiers, and a sequence counter into a single BIGINT value.
The bit layout is fixed:
| Bits | Field | Range | |---|---|---| | 63 (1 bit) | sign | always 0 (positive) | | 22-62 (41 bits) | milliseconds since custom epoch | ~69 years | | 17-21 (5 bits) | datacenter ID | 0-31 | | 12-16 (5 bits) | worker ID | 0-31 | | 0-11 (12 bits) | sequence | 0-4095 per ms |
The 41-bit timestamp supports about 69 years from the custom epoch before it overflows. For Twitter, that means until roughly 2079. For Discord, until roughly 2084. The 10 bits split between datacenter and worker give 1024 unique nodes, which is enough for most deployments. The 12-bit sequence allows 4096 IDs per millisecond per node, which is about 4 million IDs per second per worker.
Discord uses the same layout with a different epoch (2015-01-01). Every Discord message, channel, user, and role has a Snowflake ID, and decoding it reveals the creation date. Instagram used a similar 64-bit scheme with 41 bits of timestamp and 13 bits of shard ID, though Instagram's layout differs slightly from Twitter's. The tool supports the Instagram epoch (2011-08-25) for decoding IDs from Instagram's early infrastructure.
Snowflake IDs are monotonically increasing within a single worker because the timestamp always moves forward and the sequence increments within a millisecond. Across workers, IDs are roughly sortable by time but not strictly ordered because clocks drift between machines. For generating new Snowflake IDs with a configurable epoch and worker ID, see the Snowflake ID Generator.
How to use this tool
- Select the platform from the dropdown: Twitter/X (epoch 1288834974657), Discord (epoch 1420070400000), Instagram (epoch 1314220021721), or Custom.
- If you selected Custom, enter the epoch in milliseconds used by your Snowflake generator.
- Paste a numeric Snowflake ID into the input field. The tool accepts any non-negative integer.
- Check the decoded timestamp (ISO date and Unix milliseconds), datacenter ID, worker ID, and sequence number in the settings panel.
- Review the 64-bit binary representation and the color-coded bit field breakdown to see how each field maps to specific bit positions.
- If the timestamp looks wrong, verify you selected the correct platform epoch. A Discord ID decoded with the Twitter epoch will show a timestamp off by about 4 years.
Real-world examples
Finding when a Discord message was sent
Input: `175928847299117063` with platform set to Discord (epoch 1420070400000). The tool extracts the 41-bit timestamp, adds the Discord epoch, and produces an ISO date of 2016-04-30T01:18:43.287Z. The datacenter ID is 0, worker ID is 1, and sequence is 7. This tells a moderator exactly when the message was created, which is useful for audit logs and incident timelines. Discord exposes message IDs in the API and in the client's developer tools.
Decoding a Twitter/X tweet ID
Input: `1288834974657499136` with platform set to Twitter/X (epoch 1288834974657). The tool decodes the timestamp to 2020-07-29T22:21:25.657Z, which is the moment the tweet was created. The worker ID and datacenter ID indicate which Twitter server generated the ID. This is useful for analyzing tweet creation patterns or verifying that a tweet was posted at a claimed time.
Using a custom epoch for an internal system
A company uses Snowflake IDs with a custom epoch of 1577836800000 (2020-01-01T00:00:00Z). They paste an ID like `1234567890123456789` and select Custom, entering 1577836800000 as the epoch. The tool decodes the timestamp relative to their epoch, showing the creation date in 2020. Without the correct epoch, the timestamp would be off by decades, which is a common debugging issue when working with non-standard Snowflake implementations.
Inspecting the bit field breakdown
Input: `175928847299117063` with Discord epoch. The binary representation is `000010011100010011101100010100010010010100000000000000000000111`. The tool splits this into timestamp (41 bits: `00001001110001001110110001010001001001010`), datacenter (5 bits: `00000`), worker (5 bits: `00001`), and sequence (12 bits: `000000000111`). The visual bar shows the relative sizes of each field, making it clear that the timestamp occupies the majority of the 64-bit space.
Comparison with similar methods
| Method | Complexity | Typical use |
|---|---|---|
| Snowflake (Twitter/X, Discord, Instagram) | 64-bit, 41-bit timestamp + 10-bit machine + 12-bit sequence | Distributed systems, social media platforms |
| UUID v1 | 128-bit, 60-bit timestamp + node ID, RFC 9562 | Standard time-based UUIDs |
| UUID v7 | 128-bit, 48-bit Unix timestamp + random, RFC 9562 | Sortable database primary keys |
| ULID | 128-bit, 48-bit timestamp + 80-bit random | Sortable IDs, single-process |
| Auto-increment integer | 32 or 64-bit, sequential | Single-server databases |
Limitations or considerations
This tool decodes Snowflake IDs using the standard Twitter 64-bit layout. If your system uses a different bit allocation (some implementations use 10 bits for worker and 12 bits for sequence, others use different splits), the decoded fields will be wrong. The tool assumes the Twitter layout: 41 bits timestamp, 5 bits datacenter, 5 bits worker, 12 bits sequence.
The tool does not validate that the ID was generated by the selected platform. You can decode a Twitter ID with the Discord epoch, and the tool will produce a timestamp that is off by the difference between the two epochs (about 4 years). Always verify the platform epoch matches the source of the ID.
JavaScript BigInt is used for all arithmetic because the 64-bit values exceed the safe integer range of JavaScript's Number type (2^53). If you are working with Snowflake IDs in JavaScript code, always use BigInt or a dedicated 64-bit integer library. Using Number will silently lose precision for IDs above 9007199254740992.
The tool does not detect clock rollback or sequence overflow. If a Snowflake generator experienced clock rollback during ID creation, the decoded timestamp may be inaccurate. The original Twitter Snowflake implementation rejected IDs when the system clock moved backward, but not all implementations do this.
Frequently asked questions
What epoch does Discord use for Snowflake IDs?
Discord uses 1420070400000, which is 2015-01-01T00:00:00.000Z in milliseconds. Twitter uses 1288834974657 (2010-11-04T01:42:54.657Z). Instagram uses 1314220021721 (2011-08-25T17:07:01.721Z). To decode a Discord ID, select Discord from the platform dropdown and paste the ID.
Why does JavaScript need BigInt for Snowflake IDs?
Snowflake IDs are 64-bit integers, which can exceed 2^53 (9007199254740992). JavaScript's Number type uses 64-bit floating-point, which loses integer precision above 2^53. A Snowflake ID like 175928847299117063 is above this threshold, so Number would round it to 175928847299117060, corrupting the lower bits. BigInt handles the full 64-bit range without precision loss.
How accurate is the decoded timestamp?
The timestamp is accurate to the millisecond, assuming the ID was generated by a correctly implemented Snowflake generator with the selected epoch. If the generator experienced clock drift or clock rollback, the timestamp may be slightly off. The original Twitter implementation used NTP and rejected IDs when the clock moved backward, but not all implementations do this.
Can I decode Snowflake IDs from any platform?
Only if the platform uses the Twitter 64-bit layout (41-bit timestamp, 5-bit datacenter, 5-bit worker, 12-bit sequence). Some systems use different bit splits. For example, Instagram used 41 bits of timestamp and 13 bits of shard ID, which means the datacenter and worker fields would be decoded incorrectly by this tool. The Instagram epoch is supported, but the bit field breakdown follows the Twitter layout.
What happens if I use the wrong epoch?
The decoded timestamp will be off by the difference between the two epochs. For example, decoding a Discord ID with the Twitter epoch produces a timestamp about 4 years earlier than the actual creation date, because the Twitter epoch (2010-11-04) is earlier than the Discord epoch (2015-01-01). The datacenter, worker, and sequence fields are not affected by the epoch selection.
Conclusion
Snowflake IDs pack a timestamp, machine identifiers, and a sequence number into a single 64-bit integer, making them a compact way to encode when and where an object was created. This decoder supports Twitter/X, Discord, and Instagram epochs, and shows the full bit field breakdown so you can understand the layout. For generating new Snowflake IDs with a configurable epoch and worker ID, see the Snowflake ID Generator. For other developer utility tools, see the Cron Expression Parser or the UUID Generator.