Erzeuge RFC-4122-Version-4-UUIDs aus kryptographisch sicherer Zufälligkeit — einzeln oder in Stapeln, komplett lokal.
Wird lokal in deinem Browser verarbeitet
1–100 pro Stapel.
RFC 4122 Version 4 — 122 zufällige Bits aus der kryptografischen Zufallsquelle der Plattform, mit festen Version- und Variant-Feldern.
Über dieses Tool
Der UUID-Generator erzeugt Version-4-UUIDs nach RFC 4122 (universell eindeutige Identifikatoren) aus kryptographisch sicherer Zufälligkeit — getRandomValues der Plattform, dieselbe Quelle, die deine Laufzeit für sichere Identifier nutzt. Erzeuge eine UUID mit einem Klick oder bis zu 100 auf einmal für Fixtures, Seed-Daten oder Test-Suites; schalte zwischen Klein- und Großschreibung sowie zwischen Formen mit und ohne Bindestriche um, und kopiere einen einzelnen Wert oder den ganzen Stapel. Jeder erzeugte Wert wird vor der Anzeige gegen die Versions- und Varianten-Bits validiert, und der Generator validiert auch jede eingefügte UUID — er prüft Form, das Version-4-Nibble und die RFC-Varianten-Bits statt nur des Bindestrich-Musters. Die Methode wird offen gezeigt: 122 zufällige Bits mit festgelegten Versions- und Variantenfeldern, genau wie RFC 4122 Abschnitt 4.4 es festlegt. Alles läuft lokal: kein Wert, den du erzeugst oder validierst, wird hochgeladen, protokolliert oder gespeichert. Nutze dieses Tool für Testdaten, Datenbank-Keys, Ereignis-Identifier oder überall dort, wo eine v4-UUID gebraucht wird und die Zufälligkeit aus der kryptographischen Quelle der Plattform kommen soll statt aus einem geteilten Webdienst.
Wie wird das Ergebnis berechnet?
Drei Test-Fixtures
Erzeuge drei UUIDs für Seed-Daten. Jeder Wert hat das Version-4-Nibble (eine 4 in der dritten Gruppe) und die Varianten-Bits (8, 9, a oder b am Anfang der vierten Gruppe), z. B. 7f3a9c21-4d2e-4b8a-9c1e-2f3a4b5c6d7e — das Muster ist auf einen Blick sichtbar, sodass eine von Hand getippte Fälschung leicht zu erkennen ist.
Beispieleingabe und -ausgabe
Eingabe
Wert
count
3
format
lowercase, hyphenated
Ergebnis
3 gültige RFC-4122-v4-UUIDs, jede gegen Versions- und Varianten-Bits geprüft
Wie lautet die Formel und ihre Annahmen?
Konstruktion der Version 4
uuid = 122 random bits, with version = 0100 and variant = 10 fixed
Formelbegriffe
Symbol
Bedeutung
version
das hohe Nibble der dritten Gruppe, gesetzt auf 4
variant
die beiden hohen Bits der vierten Gruppe, gesetzt auf 10
Die Zufälligkeit stammt aus dem kryptographisch sicheren getRandomValues der Plattform.
Welche Fehler sind am häufigsten?
Math.random() für Identifier zu verwenden — es ist nicht kryptographisch sicher; dieses Tool nutzt getRandomValues.
Jeden 8-4-4-4-12-String als v4-UUID zu akzeptieren — die Versions- und Varianten-Bits müssen ebenfalls stimmen.
UUIDs für Fixtures von Hand zu tippen — ein falsches Zeichen und der Wert ist ungültig.
Identifier auf einem Server zu erzeugen, der sie protokolliert — dieses Tool ist vollständig lokal.
Welche Annahmen und Grenzen gelten?
Nur Version 4: Das Tool erzeugt und validiert v4; v1, v3, v5 und die zeitgeordnete v7 werden nicht unterstützt.
Die Stapelerzeugung ist auf 100 Werte pro Stapel begrenzt, damit die Seite reaktionsfähig bleibt.
Eindeutigkeit ist probabilistisch, nicht garantiert — das Tool nennt die Wahrscheinlichkeiten, statt absolute Eindeutigkeit zu versprechen.
Zuletzt geprüft 5. August 2026 · Version 1.0.0 · Toolivaro garantiert keine externen Inhalte.
Häufig gestellte Fragen
Warum hat meine erzeugte UUID immer eine 4 in der dritten Gruppe?
Das ist das Versionsfeld: RFC-4122-Version 4 setzt das hohe Nibble dieses Bytes auf 0100 (hex 4). Jede gültige v4-UUID zeigt das — es ist kein Bug, sondern das Format.
Ist garantiert, dass zwei erzeugte UUIDs unterschiedlich sind?
Kein Generator kann Eindeutigkeit garantieren — v4 bietet 122 zufällige Bits, daher sind Kollisionen astronomisch unwahrscheinlich (etwa 1 zu 2^61 bei zwei Milliarden Werten), aber nicht unmöglich. Das Tool nutzt die kryptographische Zufälligkeit der Plattform, die stärkste im Browser verfügbare Quelle.
Was prüft der Validator?
Die Form (8-4-4-4-12 Hex-Gruppen), das Version-4-Nibble und die RFC-Varianten-Bits. Ein String mit dem richtigen Bindestrich-Muster, aber der falschen Version — etwa eine v1- oder v3-UUID — wird korrekt abgelehnt.