Hoppa till innehåll
100% lokalt

Snowflake-ID-avkodare

Dela upp ett 64-bitars Snowflake-ID i dess tidsstämpel-, maskin- och sekvensfält.

Inmatning
Utmatning

Snowflake-ID-avkodare

Klistra in ett eller flera Snowflake-ID:n — de 64-bitars identifierare som används av Twitter, Discord, Instagram, Mastodon och otaliga interna system modellerade efter dem — och det här verktyget delar upp var och en av dem i sin tidsstämpel, maskinidentifierare och sekvensnummer. Varje tjänst lägger till ett Snowflake-ID till en datadel (en tweet, ett Discord-meddelande, en databasrad) så att ID:n sorteras kronologiskt och kan genereras av många maskiner samtidigt utan ett koordineringssteg.

Välj den epoch under Epoch / format som matchar din källa: Twitter och Discord delar samma bitlayout men olika startdatum, Instagram delar upp sina bitar annorlunda (ett bredare shad-fält, ingen separat worker-ID), och Mastodon hoppar över maskinsfält helt för en enkel millisekundtidsstämpel plus sekvens. Välj Anpassad och ange din egen epoch i Unix-millisekunder för något annat Snowflake-liknande schema. Visa lokal tid lägger till din enhets egen tidszon bredvid UTC-tidsstämpeln, och Visa binär uppdelning skriver ut råbitgrupperna så att du kan se exakt vilka bitar som bär vilket fält.

Byt Riktning till Datum → gräns-ID för att gå åt andra hållet: skriv ett datum (vanlig 2026-08-11 eller en fullständig ISO 8601-tidsstämpel) och få tillbaka det minsta och största Snowflake-ID som kunde existera för den millisekunden — det par som de flesta API:er förväntar sig som 'före'/'efter'-markören när de använder ID i stället för sidnumrering. Varje rad bearbetas oberoende, så du kan avkoda en helt logg med ID:n eller generera gränser för en hel lista med datum i en körning. Verktyget validerar att varje värde passar in i en 64-bitars Snowflake och rapporterar ogiltiga eller out-of-range-rader istället för att tyst hoppa över dem.

Allt körs lokalt i din webbläsare — inklistrade ID:n, datum och eventuell anpassad epoch lämnar aldrig din enhet, så det är säkert att använda med produktionsdata. Kopiera resultatet, ladda ned det som en .txt-fil eller skicka det direkt till en annan verktygs inmatning för att fortsätta arbeta med det.

FAQ

Vad är ett Snowflake-ID?
Ett 64-bitars nummer som packar en millisekundtidsstämpel, en eller två maskinidentifierare och en per-millisekund-sekvenständrare i ett enda sorterbart heltal. Twitter introducerade schemat; Discord, Instagram, Mastodon och många interna system använder varianter av det.
Varför behöver Twitter- och Discord-ID:n olika inställningar?
De delar samma bitlayout men räknar millisekunder från olika startpunkter — Twitters epok börjar i november 2010, Discords i januari 2015. Om du väljer fel får du en tidsstämpel som är många år felaktig.
Vad är skillnaden mellan avkodning och gräns-ID-riktningen?
Avkodning läser ett befintligt ID tillbaka till dess fält. Gränsriktningen gör det motsatta: givet ett datum konstruerar det det minsta och största ID som den tidsstämpeln kunde ha producerat, vilket många API:er använder som sidnumreringsmarkör.
Varför visar Instagram en shard men inget separat worker-fält?
Instagrams format tilldelar fler bitar till en enda shard-identifierare istället för att dela en datacenter-ID och ett worker-ID som Twitter och Discord gör — en avsiktlig designskillnad, inte en avkodningslucka.
Laddas mina data upp någonstans?
Nej. Varje ID, datum och anpassad epoch som du anger bearbetas helt i din webbläsare och skickas aldrig till en server.