Discord Snowflake Generator

Discord Snowflakes as pure numeric strings

This tool emits Discord Snowflakes as a plain numeric string — no formatting, no prefix, no quotes — ready to paste into a bot script, a debug log fixture or a SQL row. The generator targets specifically the Discord variant of the Snowflake family, with its epoch fixed at 1420070400000 ms (1 January 2015) and the 42 / 5 / 5 / 12 bit split that every Discord ID inherits, from user IDs to webhook IDs.

Reversing an ID to its creation timestamp

The single most useful property of a Discord Snowflake: the upper 42 bits are a millisecond timestamp relative to the Discord epoch. The formula is reversible with one shift:

// JavaScript (BigInt — the ID is too big for Number)
const id = 175928847299117063n
const ms = Number(id >> 22n) + 1420070400000
new Date(ms).toISOString() // → 2016-04-30T11:18:25.796Z

// Python (discord.py / disnake)
disnake.utils.snowflake_time(175928847299117063)

// Node (discord.js)
SnowflakeUtil.deconstruct('175928847299117063').timestamp

Concrete use cases for raw IDs

• Account-age analytics — extract the creation date of every server member without touching the audit log; old accounts have small IDs, new accounts have huge ones.
• Message sort fallback — when the Gateway delivers events out of order, sorting messages by ID is equivalent to sorting by timestamp, no extra column required.
• Bulk-action timing — clustering of consecutive IDs reveals coordinated DM spam or webhook floods within a single millisecond.
• Webhook and embed indexing — webhook IDs, embed message IDs and interaction IDs are all Snowflakes in the same namespace; a single primary-key column handles them all.
• Bot IDs equal user IDs — applications log in as users, so every bot's ID is just another Snowflake; useful when joining a bot directory against the Discord API.

Anatomy in detail

bits 63..22  timestamp  (42 bits, ms since Discord epoch)
bits 21..17  worker id  (5 bits, 0-31)
bits 16..12  process id (5 bits, 0-31)
bits 11..0   increment  (12 bits, 0-4095, resets every ms)

The 12-bit increment counter is reset every millisecond and is collision-free within the same worker/process pair. Globally, however, Snowflakes are not strictly monotonically increasing: two workers minting IDs in parallel at the same millisecond can produce IDs whose order does not match their absolute generation order. If you depend on a global total order, sort by timestamp first and break ties on the lower 22 bits.

Common debugging pitfalls

An ID of 0 means every field is zero, which decodes to the Discord epoch itself (1 Jan 2015, 00:00 UTC) — almost always a sign of an unset field, not a real entity. A 16-digit ID is suspicious: real IDs grew past 16 digits in 2018, so anything shorter is either truncated by IEEE-754 precision loss or a placeholder. External helpers like snowsta.mp decode any Snowflake against the Discord, Twitter or Instagram epoch — a convenient sanity check when an unknown ID lands in your inbox.

Privacy implications

A Discord ID encodes the exact moment its owner registered, joined a server or posted a message. Discord users see this as normal metadata, but a leaked database of IDs is effectively a leaked timeline of every account's activity to the millisecond. Treat IDs as sensitive when correlating them with handle or IP data.

FAQ

Can I discover when a Discord account was created? Yes — divide the ID by 2²², add 1420070400000 and pass the result to new Date(...). Works for users, servers, channels and messages.

Can I forge a Discord ID? No. Snowflakes are generated server-side at object creation; the API never accepts a user-supplied ID. You can mint a number that looks like a valid Snowflake (this tool does exactly that for offline tests), but Discord will not recognise it.

Does the ID ever change? No — Snowflakes are immutable for the lifetime of the object, including across renames, the 2023 handle migration, server transfers and channel renames.

Why are Snowflakes not strictly monotonic? Multiple worker/process pairs mint IDs in parallel. Within one worker the sequence is strictly increasing, but across workers two IDs can be issued out of order if they fall in the same millisecond.