Wie benutzt du dieses Tool?
- Use-Case-Rezept oben wählen — oder Länge und Zeichensatz manuell setzen.
- Anzahl bestimmen: 1 für eine einzelne ID, 10/100/1 000/10 000 für Bulk-Generate.
- Auf „Erzeugen" klicken — die ID erscheint sofort. Per „Kopieren" in die Zwischenablage oder „Als CSV speichern" exportieren.
- Im Kollisions-Akkordeon das erwartete Volumen wählen — die Wahrscheinlichkeit einer Doppelung wird live nach Birthday-Paradox berechnet.
- Für sprech- oder druckbare Codes den Zeichensatz „Ohne Verwechsler" wählen — das Read-Aloud-Badge bestätigt die Wahl.
Was ist eine Nano-ID?
Eine Nano-ID ist ein kompakter, URL-freundlicher Identifier — die kürzere Alternative zur klassischen UUID. Im Standard 21 Zeichen aus dem URL-sicheren Alphabet A–Z a–z 0–9 _ - (das ist das URL-unreservierte Zeichen-Set nach RFC 3986). Mit 64 möglichen Zeichen pro Position ergeben 21 Zeichen rund 126 Bit Entropie — vergleichbar mit UUID v4 (122 Bit), aber 15 Zeichen kürzer und ohne Bindestriche.
Drei Eigenschaften unterscheiden das Tool von der Konkurrenz, die in der Recherche analysiert wurde:
- Kollisions-Rechner inline: Während du Länge und Zeichensatz wählst, zeigt der eingebaute Akkordeon nach dem Birthday-Paradox live, wie wahrscheinlich eine Doppelung bei 1 000 / 100 000 / 1 Mio. / 1 Mrd. / 1 Bio. gezogenen IDs ist. Konkurrenz-Tools liefern entweder einen reinen Generator (ohne Math) oder einen reinen Calculator (ohne Generator) — wir kombinieren beides.
- DACH-Use-Case-Rezepte: Fünf 1-Klick-Presets für URL-Slug, API-Key, Gutschein-Code, Session-ID und Datei-Suffix. Jedes Rezept fixiert Länge UND Zeichensatz auf die für den Use-Case gängige Wahl — schluss mit dem „Welche Länge brauche ich?”-Pain.
- Ohne-Verwechsler-Modus + Read-Aloud-Badge: Der spezielle Zeichensatz „ohne 0/O/o/1/l/I” eignet sich für gedruckte oder vorgelesene Codes (Gutscheine, OCR-Bons, Support-Tickets). Ein Badge bestätigt die „Vorlese-Tauglichkeit” sofort.
Die Bedienung folgt dem Refined-Minimalism-Prinzip: Krypto-Badge oben, fünf Use-Case-Rezepte als Karten, Länge + Anzahl in zwei Spalten, Zeichensatz-Dropdown, großer „Erzeugen”-Button, Ausgabe in Mono-Schrift, Kollisions-Akkordeon. Kein Tracking, kein Konto, kein Server.
Wie funktioniert die kryptographische Zufallsquelle?
Das Tool nutzt crypto.getRandomValues() — die W3C-Web-Crypto-API, die seit 2014 in allen modernen Browsern verfügbar ist. Sie liefert nicht-vorhersagbare Bytes aus dem System-Entropie-Pool: Linux nutzt /dev/urandom, macOS nutzt einen ähnlichen random-Service, Windows nutzt seine System-Krypto-API. Diese Quellen werden kontinuierlich aus Hardware-Ereignissen (Tastatur-Timing, Maus-Bewegung, Netzwerk-Jitter, Festplatten-Latenz) nachgespeist.
Aus dem 32-Bit-Rohwert wird per Rejection-Sampling ein Index in das gewählte Alphabet gebildet — ohne Modulo-Bias, der bei byte % alphabetSize für Alphabet-Größen, die keine Zweierpotenz sind, eine ungleichmäßige Verteilung erzeugen würde. Das ist derselbe Algorithmus, den die Original-Nano-ID-Bibliothek nutzt: Maskiere mit der kleinsten 2^k − 1 ≥ alphabetSize − 1, verwerfe Werte ≥ alphabetSize, ziehe einen neuen Byte.
Der Browser-Krypto-Badge oben zeigt aktiv an, welche Quelle verwendet wird. „Browser-Krypto · kryptographische Qualität” bei crypto.getRandomValues()-Verfügbarkeit, „Pseudo-Zufall · Mathematik-basiert” im seltenen Fallback (sehr alte Browser, exotische Embedded-WebViews). So bleibt die RNG-Qualität sichtbar — Konkurrenzdienste machen das nicht.
Wie ermittelt der Kollisions-Rechner die Wahrscheinlichkeit?
Der Rechner nutzt die geschlossene Form des Birthday-Paradox:
P(Kollision) ≈ 1 − exp( −n·(n−1) / (2 · S) )mit n = Anzahl gezogener IDs und S = Alphabet-Größe hoch Länge. Die Berechnung läuft in Log-Space, damit auch bei n = 10^12 keine Zahlen überlaufen.
Ein paar Größenordnungen zur Intuition:
| Länge | Alphabet | Anzahl IDs | Wahrscheinlichkeit Doppelung |
|---|---|---|---|
| 8 | 64 (URL-safe) | 1 Mio. | ≈ 0,18 % |
| 8 | 36 (alphanum kl.) | 1 Mio. | ≈ 18 % |
| 8 | 56 (ohne Verwechsler) | 1 Mio. | ≈ 0,55 % |
| 12 | 64 (URL-safe) | 1 Mrd. | ≈ 7 × 10^-6 |
| 16 | 64 (URL-safe) | 1 Bio. | ≈ 5 × 10^-9 |
| 21 | 64 (URL-safe) | 1 Bio. | ≈ 3 × 10^-15 |
| 32 | 64 (URL-safe) | 1 Bio. | < 10^-37 |
Die Faustregel: Bei kurzen IDs (≤12 Zeichen) MUSS du das Volumen kennen; bei 21 Zeichen ist eine Doppelung selbst bei 1 Billion gezogenen IDs praktisch unmöglich. Der Rechner zeigt fünf qualitative Stufen — „Praktisch unmöglich”, „Sehr selten”, „Selten”, „Möglich”, „Wahrscheinlich” — mit farbcodiertem Badge, damit du auf einen Blick siehst, ob deine Wahl trägt.
Welche Use-Case-Rezepte gibt es?
Fünf Presets decken die häufigsten DACH-Einsatz-Szenarien ab. Jedes setzt Länge UND Zeichensatz per Klick:
URL-Slug (8 Zeichen, URL-safe). Ideal als kurzer Identifier in URLs, der per Hand lesbar und ohne Encoding-Probleme funktioniert. Beispiel: kittokit.com/p/aB3xK_7q. Suchraum 64^8 ≈ 2,8 × 10^14 — reicht für jeden Linkverkürzer und für Pastebin-artige Apps bis etwa 100 Millionen Einträge. Für Hochvolumen-URLs (>1 Mrd.) lieber 10–12 Zeichen.
API-Key (32 Zeichen, alphanumerisch ohne Symbole). Ohne _ und - für maximale Kompatibilität mit Token-Headern und Tools, die manchmal Symbole als Trenner missinterpretieren. Suchraum 62^32 ≈ 2,3 × 10^57 — kollisions-mathematisch komplett unbedenklich bei jedem realistischen Volumen.
Gutschein-Code (8 Zeichen, ohne Verwechsler). Speziell für gedruckte Codes auf Bons oder Brief-Aufklebern. Entfernt 0/O/o/1/l/I — übrig bleiben 56 Zeichen, Suchraum 56^8 ≈ 9,7 × 10^13. Bis 1 Million Codes liegt die Doppelungs-Wahrscheinlichkeit bei ca. 0,55 %, was bei Coupon-Auflagen unkritisch ist (Doppelungen werden im POS-System abgefangen).
Session-ID (21 Zeichen, URL-safe). Der Nano-ID-Standard-Default — der sicherste „one-size-fits-all”-Wert. Suchraum 64^21 ≈ 4 × 10^37, in Entropie äquivalent zu einer UUID. Sicher für Web-Sessions, persistente User-IDs und Cookie-Werte. Auch geeignet als Drop-In-Replacement für UUID v4, wenn die URL-Länge ein Argument ist.
Datei-Suffix (6 Zeichen, lowercase + Ziffern). Für temporäre Dateinamen wie report-x7k2qm.pdf oder Upload-Hashes. Lowercase passt zu den meisten Filesystem-Konventionen (Windows ist case-insensitive, Linux case-sensitive — lowercase-Wahl vermeidet beide Stolperfallen). Suchraum 36^6 ≈ 2,2 × 10^9 — bis 10 000 parallele Uploads pro User unbedenklich.
Wo sind die Grenzen des Tools?
Drei Dinge macht das Tool bewusst nicht:
- Keine UUID-Generierung: dafür gibt es den separaten UUID-Generator — klare Trennung verhindert UI-Bloat. Wer UUIDs in v4 oder v7 braucht, ist dort besser aufgehoben.
- Keine sequenziellen IDs (ULID, KSUID, Snowflake): das sind zeitbasierte Identifier mit anderen Eigenschaften (lexikographische Sortierbarkeit, eingebetteter Timestamp). Wenn Suchvolumen das rechtfertigt, kommt ein eigenes Sibling-Tool — bis dahin bewusste Lücke.
- Kein Streaming von >10 000 IDs: für höhere Volumen würde der Main-Thread blockieren. 10 000 ist der praktische Sweet-Spot zwischen „nützlich für CSV-Import-Generierung” und „bleibt im UI responsiv”. Bei echtem Hochvolumen-Bedarf eine Library serverseitig nutzen.
Was statistisch gilt: crypto.getRandomValues() ist für alle Standard-Use-Cases auditbar gleichverteilt. Browser-Hersteller testen die Implementierung gegen die NIST SP 800-22 Test Suite — 16 statistische Hypothesen-Tests, die alle modernen JavaScript-Engines bestehen.
Für Anwendungen, die echten physikalischen Zufall verlangen — kryptographische Schlüssel-Generierung für Hochsicherheits-Systeme, wissenschaftliche Studien mit doppelblinder Randomisierung — ist eine Hardware-RNG-Quelle die Referenz. Browser-Krypto deckt 99 % aller realistischen ID-Use-Cases ab, aber sie ist explizit kein Hardware-Zufallsgenerator.
Zuletzt aktualisiert: