Ga naar inhoud
TextArray1.41.0
100% lokaal

Snowflake-ID-decoder

Splits een 64-bits Snowflake-ID op in de tijdstempel-, machine- en volgnummervelden.

Invoer
Uitvoer
Gerelateerde tools
UUID-decoderOntwikkelaarstools
Unix-tijdstempelconverterCodering en conversie
ULID-generatorWillekeurige generatoren
i18n sleutel diffOntwikkelaarstools
TOML naar JSON-converterOntwikkelaarstools
SQL naar JSONOntwikkelaarstools
Snowflake-ID-decoder
Plak een of meer Snowflake-ID's — de 64-bits identifiers die door Twitter, Discord, Instagram, Mastodon en talloze interne systemen naar hun voorbeeld worden gebruikt — en dit gereedschap splitst elk daarvan op in de tijdstempel, machine-identifiers en volgnummer. Elke service voegt een Snowflake-ID toe aan een gegevensstuk (een tweet, een Discord-bericht, een databaserij) zodat ID's chronologisch sorteren en door veel machines tegelijk kunnen worden gegenereerd zonder coördinatiestap.
Kies onder Epoch / formaat de epoch die overeenkomt met je bron: Twitter en Discord delen dezelfde bitindeling maar verschillende startdatums, Instagram verdeelt zijn bits anders (een breder shard-veld, geen afzonderlijke worker-ID), en Mastodon slaat machinevelden helemaal over ten gunste van een eenvoudige milliseconde-tijdstempel plus reeks. Kies Aangepast en voer je eigen epoch in Unix-milliseconden in voor elk ander Snowflake-achtig schema. Lokale tijd weergeven voegt je eigen tijdzone naast de UTC-tijdstempel toe, en Binaire uitsplitsing weergeven geeft de ruwe bitgroepen af zodat je precies kunt zien welke bits welk veld dragen.
Schakel Richting naar Datum → grens-ID om het andersom te doen: typ een datum (gewoon 2026-08-11 of een volledige ISO 8601-tijdstempel) en ontvang de kleinste en grootste Snowflake-ID die voor dat milliseconde kon bestaan — het paar dat de meeste API's verwachten als de cursor 'voor'/'na' bij paginering per ID in plaats van per paginanummer. Elke regel wordt onafhankelijk verwerkt, dus je kunt een volledig log met ID's decoderen of grenzen voor een hele lijst met datums in één keer genereren. Het gereedschap valideert dat elke waarde in een 64-bits Snowflake past en rapporteert ongeldige of out-of-range regels in plaats van ze stilzwijgend over te slaan.
Alles wordt lokaal in je browser uitgevoerd — geplakte ID's, datums en elke aangepaste epoch verlaten je apparaat nooit, dus het is veilig om te gebruiken met productiegegevens. Kopieer het resultaat, download het als een .txt-bestand of verzend het rechtstreeks naar de invoer van een ander gereedschap om ermee door te gaan.
FAQ
Wat is een Snowflake-ID?
Een 64-bits getal dat een milliseconde-tijdstempel, één of twee machine-identifiers en een per-milliseconde-volgnummeraanwijzer in één sorteerbare integer verpakt. Twitter introduceerde het schema; Discord, Instagram, Mastodon en veel interne systemen gebruiken varianten ervan.
Waarom hebben Twitter- en Discord-ID's verschillende instellingen nodig?
Ze delen dezelfde bitindeling maar tellen milliseconden vanaf verschillende uitgangspunten — Twitters epoch begint in november 2010, Discord in januari 2015. Het kiezen van de verkeerde geeft een tijdstempel die jaren afwezig is.
Wat is het verschil tussen decoderen en de grens-ID-richting?
Decoderen leest een bestaande ID terug in zijn velden. De grensrichting doet het tegenovergestelde: gegeven een datum, bouwt het de kleinste en grootste ID die die tijdstempel had kunnen produceren, die veel API's gebruiken als pagineringscursor.
Waarom toont Instagram een shard maar geen afzonderlijk worker-veld?
Instagrams indeling wijst meer bits toe aan een enkele shard-identifier in plaats van een datacentrum-ID en een worker-ID op te splitsen zoals Twitter en Discord doen — een opzettelijk ontwerpverschil, geen decoderingslacune.
Worden mijn gegevens ergens geüpload?
Nee. Elke ID, datum en aangepaste epoch die je invoert, wordt volledig in je browser verwerkt en nooit naar een server gestuurd.