UUID / NanoID Generator
UUID v4 sofort generieren mit der Web Crypto API. Massengenerierung für Pro-Nutzer.
UUID v4
46695488-cd6a-477c-bd3b-dfc916b1b16bMassengenerierung (max. 5 im kostenlosen Plan)
NanoID
CxR___cHMyZRC1jRsciOOUUID v1 Timestamp Decoder
Was ist eine UUID?
Eine UUID (Universally Unique Identifier) ist ein 128-Bit-Bezeichner, der durch RFC 4122 (veröffentlicht 2005) und seinen Nachfolger RFC 9562 (veröffentlicht 2024, der UUID-Versionen 6, 7 und 8 hinzufügt) standardisiert ist. UUIDs sind so konzipiert, dass sie global eindeutig sind, ohne eine zentrale Registrierungsbehörde zu benötigen — jedes System kann unabhängig eine generieren, mit vernachlässigbarem Kollisionsrisiko. Sie werden als 32 Hexadezimalziffern in fünf durch Bindestriche getrennte Gruppen dargestellt, nach dem Muster xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, wobei das M-Nibble die Version kodiert (1–8) und das N-Nibble die Variante (immer 8, 9, A oder B für RFC-4122-UUIDs). Diese kanonische String-Darstellung ist 36 Zeichen lang, kleingeschrieben und nicht von der Groß-/Kleinschreibung abhängig.
UUID v4 (zufällige UUID) ist die am weitesten verbreitete Version. Sie wird generiert, indem 122 Bits mit kryptographisch zufälligen Daten gefüllt werden (die restlichen 6 Bits kodieren Version und Variante). Mit 2^122 ≈ 5,3 × 10^36 möglichen Werten ist die Geburtstagsparadox-Kollisionswahrscheinlichkeit vernachlässigbar: Sie müssten etwa 2,71 × 10^18 UUIDs generieren, bevor eine 50-prozentige Wahrscheinlichkeit für irgendeine Kollision erreicht wird. Im Vergleich: Bei einer Milliarde UUIDs pro Sekunde würde das über 85 Jahre dauern. Dies macht UUID v4 zur sicheren Standardwahl für Datenbankprimärschlüssel, Sitzungsbezeichner, Dateinamen, Korrelations-IDs und jeden Kontext, der einen eindeutigen String ohne Koordination erfordert.
UUID v1 kodiert den aktuellen Zeitstempel (mit 100-Nanosekunden-Auflösung, gezählt ab dem 15. Oktober 1582 — dem Einführungsdatum des Gregorianischen Kalenders) und die MAC-Adresse der generierenden Netzwerkschnittstelle in den letzten 12 Hex-Stellen. Diese Konstruktion garantiert zwar Eindeutigkeit (keine zwei Maschinen im selben Nanosekunden-Moment) und zeitliche Ordnung, hat aber zwei wesentliche Nachteile: Die eingebettete MAC-Adresse ist ein Datenschutzproblem, das zur Identifizierung der generierenden Maschine oder zur Verknüpfung mehrerer UUIDs mit einem einzigen Gerät genutzt werden kann. RFC 9562 führte UUID v6 als datenschutzfreundlichen, zeitgeordneten Ersatz für v1 und UUID v7 als empfohlene zeitgeordnete UUID für neue Anwendungen ein.
NanoID ist eine moderne Bezeichner-Bibliothek (kein IETF-Standard), die als kompakte, URL-sichere Alternative zu UUID entwickelt wurde. Mit einem 64-Zeichen-Alphabet (A–Z, a–z, 0–9, _, -) und 21 Zeichen Länge bietet NanoID eine Kollisionsresistenz, die der von UUID v4 entspricht — bei 21 Zeichen gegenüber UUIDs 36, einer Verringerung um 42 %. Das macht NanoIDs attraktiv für Anwendungsfälle, in denen IDs in URLs erscheinen, von Nutzern eingegeben werden oder in platzbeschränkten Umgebungen gespeichert werden. NanoID verwendet die Web Crypto API (getRandomValues()) für sichere Entropie — dieselbe Quelle wie für die UUID-v4-Generierung.
So verwenden Sie diesen Generator
- Einzelne UUID — Klicken Sie auf „Generieren" im UUID-v4-Bereich, um eine einzelne kryptographisch sichere zufällige UUID zu erstellen. Das Kopiersymbol neben der UUID kopiert sie in Ihre Zwischenablage. Bei jedem Klick wird eine neue UUID generiert — jede ist unabhängig zufällig und nicht von einer vorherigen abgeleitet.
- Massengenerierung — Stellen Sie die gewünschte Anzahl über die Zahleneingabe ein und klicken Sie auf „Generieren" im Massenbereich. Kostenlose Nutzer können bis zu 5 UUIDs auf einmal generieren; Pro-Nutzer bis zu 1.000. Jede UUID in der Liste wird unabhängig über die Web Crypto API generiert. Verwenden Sie „Alle kopieren", um die gesamte Liste zu kopieren — eine UUID pro Zeile, bereit zum Einfügen in SQL-Skripte oder Fixture-Dateien.
- NanoID — Klicken Sie auf „Generieren", um eine kompakte, URL-sichere NanoID im 21-Zeichen-Format mit 64-Zeichen-Alphabet zu erstellen. NanoIDs eignen sich für URL-Pfadsegmente, kurze nutzerseitige IDs und jeden Kontext, in dem das vollständige 36-Zeichen-UUID-Format zu lang wäre.
- v1 Timestamp Decoder — Fügen Sie eine beliebige UUID v1 ein (Format: xxxxxxxx-xxxx-1xxx-xxxx-xxxxxxxxxxxx — beachten Sie die führende 1 in der dritten Gruppe), um den eingebetteten Erstellungszeitpunkt zu extrahieren und anzuzeigen. Nützlich für forensische Analysen, das Debuggen von Legacy-Systemen oder das Verstehen, wann eine UUID generiert wurde.
Alle UUID- und NanoID-Generierung verwendet die Web Crypto API des Browsers: crypto.randomUUID() (für UUID v4) und crypto.getRandomValues() (für NanoID und Massengenerierung). Dies ist dieselbe kryptographische Entropiequelle wie für die TLS-Schlüsselgenerierung und bietet echte CSPRNG-Sicherheit (Cryptographically Secure Pseudo-Random Number Generation). Es werden keine Daten an einen Server übertragen.
Wie es funktioniert
UUID-v4-Generierung verwendet crypto.randomUUID(), eine native Browser-API, die in Chrome 92, Firefox 95, Safari 15.4 und Edge 92 eingeführt wurde. Diese Funktion generiert 128 zufällige Bits aus dem CSPRNG des Betriebssystems (auf Linux: getrandom()-Syscall oder /dev/urandom; auf macOS/iOS: SecRandomCopyBytes; auf Windows: BCryptGenRandom), setzt das Versions-Nibble auf 4 in den Bits 76–79, das Varianten-Nibble auf 8/9/A/B in den Bits 64–65 und formatiert das Ergebnis als Standard-UUID-String. Für ältere Browser verwendet ein Polyfill crypto.getRandomValues() mit einem Uint8Array aus 16 Bytes und wendet dieselbe Bit-Manipulation an.
NanoID-Generierung verwendet einen sorgfältig konstruierten Algorithmus: crypto.getRandomValues() füllt einen Puffer mit zufälligen Bytes, und jedes Byte wird mithilfe einer Bitmaske (Byte & 63) einem der 64 Alphabetzeichen zugeordnet. Dies gewährleistet eine mathematisch gleichmäßige Verteilung über alle 64 Zeichen — kein Zeichen ist geringfügig wahrscheinlicher als ein anderes, was die effektive Entropie reduzieren würde. Der resultierende 21-Zeichen-String hat log₂(64^21) ≈ 126 Bits Entropie, vergleichbar mit UUID v4s 122 Bits.
Der UUID-v1-Timestamp-Decoder rekonstruiert den eingebetteten Erstellungszeitpunkt, indem er die drei zeitbezogenen Gruppen des UUID-Strings parst. UUID v1 speichert einen 60-Bit-Timestamp in aufgeteiltem Format: Die niedrigen 32 Bits des Timestamps befinden sich in der ersten UUID-Gruppe, die nächsten 16 Bits in der zweiten Gruppe und die hohen 12 Bits in der dritten Gruppe (mit entferntem Versions-Nibble). Der Decoder setzt diese Segmente zusammen, subtrahiert den UUID-Epoche-Offset (122.192.928.000.000.000 Hundert-Nanosekunden-Intervalle vom 15. Oktober 1582 bis zum 1. Januar 1970) und konvertiert das Ergebnis in einen Unix-Millisekunden-Timestamp für die Anzeige.
Anwendungsfälle
Datenbankprimärschlüssel und verteilte ID-Generierung
UUID v4 als Primärschlüssel ermöglicht verteilte ID-Generierung ohne zentrale Sequenz: Jeder Microservice, jeder Mobile-Client oder jede Offline-Anwendung kann Datensätze unabhängig erstellen und später ohne Konflikte synchronisieren. Besonders wertvoll in Offline-First-Anwendungen, Multi-Region-Datenbankreplikation und Microservice-Architekturen, wo ein zentraler ID-Generator ein Engpass wäre. In PostgreSQL den nativen uuid-Spaltentyp (16 Bytes) statt VARCHAR(36) (36 Bytes) verwenden — 55 % Speicherreduktion und schnellere Indexoperationen.
Test-Fixtures, Seed-Daten und Migrationen
Verwenden Sie die Massengenerierung, um Hunderte eindeutiger IDs für Datenbank-Seed-Skripte, SQL-INSERT-Statements, Test-Fixture-JSON-Dateien oder Migrationsskripte zu erzeugen. Feste IDs in Test-Fixtures machen Tests über Umgebungen hinweg reproduzierbar. Generieren Sie einen Batch, weisen Sie IDs den Testentitäten in Ihrer Fixture-Datei zu und referenzieren Sie sie in verwandten Entity-Fremdschlüsseln. Jede generierte UUID ist unabhängig zufällig und garantiert eindeutig.
Session-Token, API-Schlüssel und Idempotenz-Keys
UUID v4s 122 zufällige Bits machen es sicher gegen Brute-Force-Enumeration-Angriffe — es gibt kein vorhersehbares Muster, das ein Angreifer ausnutzen könnte. Session-Token, API-Schlüssel, Einladungslinks, Passwort-Reset-Token und OAuth-State-Parameter profitieren alle von UUID-Level-Zufälligkeit. Für API-Idempotenz (Verhinderung von Mehrfachabbuchungen in Zahlungssystemen) stellt eine UUID v4 als Idempotency-Key-Header sicher, dass der Server auch bei Wiederholungsanfragen sicher deduplizieren kann.
Datei- und Ressourcenbenennung für Datenschutz und Kollisionsvermeidung
Benennen Sie hochgeladene Dateien, generierte Berichte, Cache-Einträge und temporäre Ressourcen mit UUIDs, um zwei kritische Probleme zu vermeiden: (1) Dateinamen-Kollisionen, wenn mehrere Nutzer Dateien mit demselben Namen hochladen, und (2) vorhersehbare Dateinamen, die private Dokumente für unbefugten Zugriff zugänglich machen könnten. Im EU/DSGVO-Kontext vermeidet die Verwendung von UUIDs für Dateinamen auch das Einbetten nutzeridentifizierender Informationen (Namen, IDs) in Dateipfade, die möglicherweise geloggt werden.
Beispiel: UUID v4 in verschiedenen Kontexten
So wird eine UUID v4 in verschiedenen typischen Entwicklungsszenarien verwendet — als Datenbankprimärschlüssel, API-Idempotenz-Key und in Python-Code:
Generierte UUID v4:
f47ac10b-58cc-4372-a567-0e02b2c3d479
SQL-Primärschlüssel:
INSERT INTO invoices (id, invoice_number, amount)
VALUES ('f47ac10b-58cc-4372-a567-0e02b2c3d479', 'RE-2025-001', 1234.56);
JavaScript API-Aufruf:
const response = await fetch('/api/invoices', {
method: 'POST',
headers: { 'Idempotency-Key': 'f47ac10b-58cc-4372-a567-0e02b2c3d479' },
body: JSON.stringify(invoiceData)
});
Python-Generierung:
import uuid
correlation_id = str(uuid.uuid4())
# => 'f47ac10b-58cc-4372-a567-0e02b2c3d479'Die 4 in der dritten Gruppe (4372) identifiziert dies als UUID der Version 4; das a (erstes Zeichen der vierten Gruppe, a567) identifiziert dies als Variante-1-UUID gemäß RFC 4122.
Tipps & Einschränkungen
Tipps
- Verwenden Sie in PostgreSQL den nativen uuid-Spaltentyp (16-Byte-Speicher) und die Funktion gen_random_uuid() anstelle einer VARCHAR(36)-Spalte mit anwendungsgenerierten Werten. Das reduziert den Speicherplatz um 55 % und liefert native UUID-Vergleichsoperatoren.
- Für Tabellen mit hoher Einfügerate (Millionen Zeilen pro Tag) verursacht UUID v4s zufällige Einfügereihenfolge B-Tree-Indexfragmentierung. Verwenden Sie UUID v7 (zeitgeordnet, neu in RFC 9562) oder ULID für bessere Indexlokalität und Bereichsabfrage-Performance.
- NanoIDs sind ideal für URL-sichere Bezeichner in REST-API-Pfaden, URL-Kürzern und nutzerseitigen IDs. Die 21-Zeichen-Länge mit 64-Zeichen-Alphabet bietet ≈126 Bits Entropie — praktisch dieselbe Kollisionsresistenz wie UUID v4.
- Massengenerierte UUIDs werden zeilenweise ausgegeben und können direkt in SQL-Skripte, CSV-Import-Dateien oder Fixture-JSON eingefügt werden.
Einschränkungen
- UUID v4 ist zufällig geordnet und daher nicht lexikographisch nach Erstellungszeit sortierbar. Für sortierbare IDs verwenden Sie UUID v7 (RFC 9562) oder ULID. In PostgreSQL empfehlen sich die Erweiterungen pgcrypto oder pg_ulid.
- UUID v1 gibt potenziell die MAC-Adresse der generierenden Maschine in den letzten 12 Hex-Stellen preis. Dies ist ein bekanntes, in RFC 4122 selbst dokumentiertes Datenschutzproblem. Verwenden Sie niemals UUID v1 in datenschutzsensiblen Kontexten — nutzen Sie stattdessen UUID v4 oder UUID v7.
- Kostenlose Nutzer können maximal 5 UUIDs auf einmal im Massenmodus generieren. Ein Pro-Konto schaltet die Massengenerierung von bis zu 1.000 UUIDs pro Batch frei.
- NanoIDs sind URL-sicher, aber nicht interoperabel mit Systemen, die das Standard-UUID-Trennstrichformat (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) erwarten. Wenn Ihr Datenbankschema, API-Vertrag oder Integrationspartner UUIDs erwartet, verwenden Sie UUID v4.
Häufig gestellte Fragen
Sind UUID-v4-Werte wirklich eindeutig?
In der Praxis ja — die Kollisionswahrscheinlichkeit ist für jede reale Anwendung vernachlässigbar gering. UUID v4 hat 122 zufällige Bits (die anderen 6 Bits kodieren Version und Variante) und ergibt 2^122 ≈ 5,3 × 10^36 mögliche Werte. Nach dem Geburtstagsparadoxon müssten Sie etwa 2,71 × 10^18 UUIDs generieren, bevor eine 50-prozentige Chance für eine einzige Kollision besteht. Bei einer Milliarde UUIDs pro Sekunde würde das über 85 Jahre dauern. Das einzige realistische Kollisionsszenario ist ein defekter Zufallsgenerator — weshalb unser Tool die Web Crypto API statt Math.random() verwendet.
Soll ich UUID v4 oder NanoID für mein Projekt verwenden?
Verwenden Sie UUID v4, wenn Interoperabilität wichtig ist: Wenn Ihr Datenbankschema, API-Vertrag oder Integrationspartner das standardmäßige 36-Zeichen-Trennstrichformat erwartet, nutzen Sie UUID v4. Das Format ist universell anerkannt und wird nativ in PostgreSQL, MySQL, MongoDB und den meisten ORMs unterstützt. Verwenden Sie NanoID, wenn Kompaktheit wichtig ist: Wenn IDs in URLs erscheinen, von Nutzern angezeigt werden oder in platzbeschränkten Umgebungen gespeichert werden, sind NanoIDs 21 Zeichen bedeutsam kürzer. Beide bieten äquivalente Kollisionsresistenz.
Sollte ich UUID v4 als Datenbankprimärschlüssel verwenden?
Das hängt von Ihrer Datenbank und dem Einfügevolumen ab. UUID v4s Zufälligkeit verursacht B-Tree-Indexfragmentierung in RDBMS wie PostgreSQL und MySQL, weil jede neue Zeile an einer zufälligen Indexposition statt am Ende eingefügt wird, was zu Seitenaufspaltungen und verschwendetem Platz führt. Bei geringem bis moderatem Einfügevolumen (unter ~10.000 Zeilen/Sekunde) ist die Fragmentierung vernachlässigbar. Bei hohem Volumen UUID v7 (zeitgeordnet, RFC 9562) oder ULID verwenden. Immer den nativen uuid-Spaltentyp von PostgreSQL (16 Bytes) statt varchar(36) (36 Bytes) nutzen.
Sind die generierten UUIDs kryptographisch sicher?
Ja. Unser Generator verwendet crypto.randomUUID() (für UUID v4) und crypto.getRandomValues() (für NanoID und Massengenerierung) — beide Teil der W3C Web Cryptography API. Diese APIs beziehen Entropie aus dem CSPRNG des Betriebssystems: getrandom() unter Linux, SecRandomCopyBytes unter macOS/iOS und BCryptGenRandom unter Windows. Dies ist dieselbe Entropiequelle wie bei der TLS-Session-Schlüsselgenerierung — um Größenordnungen sicherer als Math.random(), das nicht kryptographisch sicher ist.
Was ist der Unterschied zwischen UUID v1, v4, v6 und v7?
UUID v1 (RFC 4122, 2005): Timestamp + MAC-Adresse. Zeitgeordnet, gibt aber Geräteidentität preis. Für neue Verwendungen veraltet. UUID v4 (RFC 4122, 2005): 122 zufällige Bits. Am weitesten verbreitet; nicht zeitgeordnet. UUID v6 (RFC 9562, 2024): Neugeordneter v1-Timestamp für lexikographische Sortierbarkeit + zufälliges Knoten-Feld (kein MAC-Leck). Zeitgeordneter v1-Ersatz. UUID v7 (RFC 9562, 2024): 48-Bit-Unix-Millisekunden-Timestamp-Präfix + 74 zufällige Bits. Lexikographisch sortierbar, datenschutzkonform und empfohlen für neue Anwendungen, die sowohl Eindeutigkeit als auch Zeitordnung benötigen.
Was ist ein ULID und wie verhält es sich zu UUID?
Ein ULID (Universally Unique Lexicographically Sortable Identifier) ist ein 26-stelliger Bezeichner mit Crockfords Base32-Alphabet (0–9 und A–Z ohne I, L, O, U zur Vermeidung visueller Mehrdeutigkeiten). Er besteht aus einem 48-Bit-Millisekunden-Timestamp-Präfix gefolgt von 80 Bits Zufallsdaten. ULIDs sind case-insensitiv, URL-sicher und lexikographisch sortierbar — das Timestamp-Präfix stellt sicher, dass sequenziell generierte ULIDs in Erstellungsreihenfolge sortieren. Sie sind kein IETF-Standard, aber weit verbreitet im Node.js-Ökosystem. Für standardisierte zeitgeordnete Bezeichner UUID v7 (RFC 9562) bevorzugen.
Was ist NanoID und wie verhält es sich zu UUID v4?
NanoID (github.com/ai/nanoid) ist ein kompakter, URL-sicherer Bezeichner-Generator mit einem 64-Zeichen-Alphabet (A–Za–z0–9_-) und Web Crypto API-Entropie. Mit 21 Zeichen erreicht NanoID ≈126 Bits Entropie (log₂(64^21)), vergleichbar mit UUID v4s 122 Bits, bei 42 % geringerer Länge als UUIDs 36 Zeichen. NanoIDs sind kein IETF-Standard und enthalten keine Versions-/Variantinformationen. Sie sind nicht universell als eindeutige Bezeichner erkennbar wie UUIDs. Verwenden Sie NanoID, wenn Kompaktheit und URL-Sicherheit die Interoperabilität überwiegen; UUID v4 für alle Systeme, die Bezeichner mit externen Parteien austauschen müssen.
Kann UUID v1 meine MAC-Adresse preisgeben?
Ja — dies ist ein in RFC 4122 selbst dokumentiertes Datenschutzproblem. UUID v1 speichert die MAC-Adresse der generierenden Netzwerkschnittstelle in den letzten 12 Hex-Stellen (das Knoten-Feld). Jedes System, das eine UUID v1 empfängt, kann diese MAC-Adresse extrahieren und zur Identifizierung der generierenden Maschine nutzen, mehrere UUIDs demselben Gerät zuordnen oder potenziell den physischen Standort eines Servers eingrenzen. Moderne Betriebssysteme verwenden manchmal einen zufälligen Knotenwert statt der tatsächlichen MAC-Adresse, aber darauf zu verlassen ist nicht sicher. Verwenden Sie UUID v4 oder v7 für alle neuen Anwendungen.
Wie generiere ich UUIDs für das Datenbank-Seeding?
Verwenden Sie den Massen-UUID-Generator: Stellen Sie die Anzahl ein (Pro: bis zu 1.000), klicken Sie auf Generieren, dann auf „Alle kopieren". Die Ausgabe ist eine UUID pro Zeile, geeignet für direktes Einfügen in eine Textdatei, ein SQL-Skript oder CSV. Für SQL-Seeding können Sie INSERT-Statements konstruieren, indem Sie jede UUID in Ihrem Editor mit anderen Seed-Daten kombinieren. Alternativ bieten die meisten Datenbanken native UUID-Generierung: PostgreSQL hat gen_random_uuid(), MySQL 8 hat UUID(), und SQLite kann hex(randomblob(16)) mit entsprechender Formatierung verwenden.
Was ist das Format einer UUID und wie validiere ich eine?
Das Standard-UUID-Format ist 8-4-4-4-12 Hexadezimalziffern, durch Bindestriche getrennt: xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx, wobei M die Versionsziffer (1–8) und N 8, 9, a oder b ist (Variante). Die Gesamtlänge beträgt immer 36 Zeichen (32 Hex-Ziffern + 4 Bindestriche). Zur Validierung mit einem Regex: /^[0-9a-f]{8}-[0-9a-f]{4}-[1-8][0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i. Viele Systeme akzeptieren auch UUIDs ohne Bindestriche (32 Hex-Ziffern) oder in Großschreibung — prüfen Sie die Anforderungen Ihres Zielsystems. PostgreSquels uuid-Typ akzeptiert beide Formen unabhängig von der Schreibweise.