Erzeugen Sie kryptographisch sichere Zufallstoken im Hex-, Base64URL- oder alphanumerischen Format — in Ihrem Browser.
API-Schlüssel, Session-IDs, Webhook-Secrets, Passwort-Reset-Codes und CSRF-Token teilen eine Anforderung: Sie müssen unmöglich zu erraten sein. Das schließt Math.random(), Zeitstempel und alles davon Abgeleitete aus — die sind vorhersehbar genug, um per Brute Force geknackt zu werden. Dieser Generator verwendet crypto.getRandomValues, den kryptographisch sicheren Pseudozufallszahlengenerator (CSPRNG), den Browser aus Betriebssystem-Entropie speisen — dieselbe Quelle, mit der TLS-Schlüssel erzeugt werden.
Die Längenoption legt fest, wie viele Zufallsbytes jedes Token enthält (16 bis 128, Standard 32) — bzw. im alphanumerischen Modus, wie viele Zeichen. Hex kodiert jedes Byte als zwei Zeichen aus 0-9a-f; Base64URL packt dieselben Bytes in eine kürzere, URL-sichere Zeichenkette aus Buchstaben, Ziffern, Minus und Unterstrich; alphanumerisch zieht Zeichen aus dem 62-Zeichen-Satz A-Z a-z 0-9. Der alphanumerische Modus verdient eine technische Anmerkung: Da 256 nicht durch 62 teilbar ist, würde die naive Berechnung jedes Zufallsbytes modulo 62 manche Zeichen häufiger erscheinen lassen als andere (Modulo-Bias). Dieser Generator nutzt stattdessen Rejection Sampling — Bytes ab 248 werden verworfen und neu gezogen —, sodass jedes Zeichen exakt gleich wahrscheinlich ist.
Die Statuszeile zeigt die geschätzte Entropie: 8 Bit pro Byte für Hex und Base64URL, log2(62) ≈ 5,95 Bit pro Zeichen für alphanumerisch. Als Faustregel gilt: 128 Bit sind bereits per Brute Force nicht zu knacken, und 256 Bit — der 32-Byte-Standard — sind der Maßstab für langlebige API-Schlüssel. Alles wird lokal in Ihrem Browser erzeugt, kein Server sieht die Token je, und sie sind als echte Secrets verwendbar. Behandeln Sie sie entsprechend: Speichern Sie serverseitig nur einen Hash des Tokens, zeigen Sie den Klartext nur einmal an und rotieren Sie Schlüssel, deren Offenlegung Sie vermuten.
Entropie = Länge × log2(Alphabetgröße). Ein 32-Byte-Token trägt in jeder Kodierung 256 Bit Entropie; ein alphanumerisches Token trägt log2(62) ≈ 5,95 Bit pro Zeichen, 43 alphanumerische Zeichen ≈ 256 Bit.
32 Bytes (256 Bit) sind ein solider Standard für langlebige API-Schlüssel, 16 Bytes (128 Bit) das praktische Minimum für alles Sicherheitsrelevante. Längere Token kosten hier nichts — seien Sie also großzügig.
Es ist die ungleiche Verteilung, die entsteht, wenn 256 Bytewerte auf ein Alphabet abgebildet werden, das 256 nicht glatt teilt — manche Zeichen werden etwas wahrscheinlicher, was die effektive Entropie messbar senkt. Dieses Tool vermeidet das mit Rejection Sampling und verwirft Bytes oberhalb des größten exakten Vielfachen der Alphabetgröße.
Nein. Die Token werden lokal von crypto.getRandomValues erzeugt und nie übertragen, protokolliert oder gespeichert — diese Seite stellt keine Netzwerkanfragen, die Token sind also als echte Secrets verwendbar.
Nur die Kodierung — die Zufallsquelle ist dieselbe. Hex ist am längsten, aber universell parsebar; Base64URL ist rund ein Drittel kürzer und sicher in URLs; alphanumerisch vermeidet jede Interpunktion, was hilft, wenn ein System die erlaubten Zeichen einschränkt.
Theoretisch ja, praktisch nein: Bei 256 Bit liegt die Wahrscheinlichkeit, je ein Duplikat zu sehen, weit unter der eines Hardwarefehlers. Kollisionsresistenz ist genau der Grund, warum unvorhersehbare Zufallstoken gute Bezeichner für Secrets sind.
Vai.la verwandelt jede URL in einen Kurzlink mit Klick-Statistiken, QR-Code und Ihrem eigenen Biolink.
Vai.la übernimmt keine Verantwortung für die Nutzung der Tools oder für Entscheidungen, die auf ihren Ergebnissen basieren.