tooloora

UUID-Generator – v4 und v7, einzeln oder als Liste

Zufällige UUID v4 oder zeitlich sortierbare UUID v7 erzeugen, 1 bis 100 auf einmal, einzeln oder als ganze Liste kopieren. Lokal per Web Crypto erzeugt, nichts wird gesendet.

Läuft lokal — nichts wird hochgeladen

    Wird lokal mit der Web-Crypto-API deines Browsers erzeugt – nichts wird gesendet.

    UUIDs erzeugen: v4 und v7

    Erzeuge 1 bis 100 UUIDs auf einmal, wahlweise als zufällige v4 oder zeitlich sortierbare v7, mit Großschreibungs-Option, Einzel-Kopie je Zeile und Alles-kopieren. Die Zufallsbits stammen aus der Web-Crypto-API deines Browsers, einer kryptografisch sicheren Quelle. Nichts wird an einen Server gesendet, das Tool funktioniert offline.

    Was ist eine UUID?

    Ein Universally Unique Identifier ist ein 128-Bit-Wert, dargestellt als 36 Zeichen in fünf Hex-Gruppen (8-4-4-4-12). Der aktuelle Standard ist RFC 9562 (Mai 2024), der das ältere RFC 4122 ablöst und neben den klassischen Versionen die neuen zeitbasierten Versionen 6, 7 und 8 definiert. UUIDs lassen sich dezentral erzeugen, ohne zentrale Vergabestelle, und kollidieren praktisch nie: Eine v4-UUID trägt 122 Zufallsbits, also rund 5,3 × 10^36 mögliche Werte.

    v4 oder v7, welche solltest du nehmen?

    • v4 (zufällig): maximale Anonymität, verrät nichts über Zeitpunkt oder Reihenfolge der Erzeugung. Gut für öffentlich sichtbare IDs, Tokens, Dateinamen.
    • v7 (zeitbasiert): beginnt mit einem 48-Bit-Unix-Millisekunden-Zeitstempel, gefolgt von 74 Zufallsbits (RFC 9562 §5.7). v7-Werte sortieren sich grob nach Erzeugungszeit, was sie zu deutlich besseren Datenbank-Primärschlüsseln macht: Neue Zeilen landen im Index beieinander statt kreuz und quer, das reduziert Page-Splits und Cache-Misses gegenüber v4-Schlüsseln.

    Kurz: Datenbank-Schlüssel → v7, alles andere → v4.

    Wie ehrlich ist die v7-Sortierbarkeit hier?

    Unsere v7-Implementierung folgt RFC 9562, verzichtet aber bewusst auf den optionalen Monotonie-Zähler: UUIDs aus derselben Millisekunde teilen sich das Zeit-Präfix, der Rest ist Zufall, ihre relative Reihenfolge ist also nicht definiert. Über Millisekunden-Grenzen hinweg stimmt die Sortierung immer. Für die allermeisten Zwecke (Datenbank-Keys, Log-Korrelation) reicht das; wer strikte Monotonie braucht, ergänzt einen Zähler in der Datenbank.

    Zweite ehrliche Anmerkung: Eine v7-UUID enthält ihre Erzeugungszeit im Klartext, jeder kann die ersten 48 Bits als Timestamp lesen. Ist das unerwünscht, nimm v4.

    Woher kommt der Zufall?

    Aus crypto.randomUUID beziehungsweise crypto.getRandomValues, dem kryptografisch sicheren Zufallsgenerator des Browsers, nicht aus Math.random. Alles passiert lokal auf deinem Gerät: Kein Server erzeugt, sieht oder protokolliert deine IDs.

    Häufige Fragen

    Was ist der Unterschied zwischen UUID v4 und v7?

    v4 ist komplett zufällig: 122 der 128 Bits stammen aus einer kryptografischen Zufallsquelle. v7, standardisiert in RFC 9562 (Mai 2024), beginnt mit einem 48-Bit-Unix-Millisekunden-Zeitstempel, gefolgt von 74 Zufallsbits. v7-Werte sortieren sich dadurch grob nach Erzeugungszeit, was sie zu besseren Datenbank-Primärschlüsseln macht, weil Inserts im Index beieinander bleiben. v4 verrät dafür nichts über den Erzeugungszeitpunkt.

    Werden die UUIDs auf einem Server erzeugt?

    Nein. Jede UUID entsteht in deinem Browser über die Web-Crypto-API (crypto.randomUUID und crypto.getRandomValues), eine kryptografisch sichere Zufallsquelle. Es wird nichts von einem Server angefragt oder dorthin gesendet, niemand sonst sieht deine Bezeichner, und das Tool funktioniert offline.

    Können zwei erzeugte UUIDs kollidieren?

    Praktisch nein. Eine v4-UUID hat 122 Zufallsbits, also rund 5,3 Undezillionen (5,3 × 10^36) mögliche Werte. Man müsste grob 100 Billionen UUIDs erzeugen, bevor die Kollisionswahrscheinlichkeit auch nur eins zu einer Milliarde erreicht. Kollisionen sind ein theoretisches, kein praktisches Problem, solange eine echte Zufallsquelle genutzt wird, und das ist hier der Fall.

    Ist die v7-Reihenfolge innerhalb derselben Millisekunde garantiert?

    Nein, und dieses Tool ist da ehrlich: Unsere v7-Implementierung hat keinen Monotonie-Zähler. UUIDs aus derselben Millisekunde teilen sich das Zeitstempel-Präfix, der Rest ist Zufall, ihre relative Reihenfolge ist also unbestimmt. Über Millisekunden-Grenzen hinweg stimmt die Sortierung. RFC 9562 beschreibt optionale Zähler-Methoden für strikte Monotonie; Datenbanken, die das brauchen, ergänzen meist eigene.

    Verrät eine v7-UUID etwas über mich?

    Sie enthält ihre Erzeugungszeit: Die ersten 48 Bits sind der Unix-Timestamp in Millisekunden, den jeder auslesen kann. Das ist so gewollt und meist unkritisch. Ist aber schon der Erzeugungszeitpunkt sensibel, nimm v4, das außer Zufall nichts kodiert.