Base64 vs. Base64URL vs. Base32: Was sollten Sie verwenden?

// DIE SCHNELLE VERGLEICHSTABELLE

                 Base64          Base64URL        Base32
                 (RFC 4648 §4)   (RFC 4648 §5)    (RFC 4648 §6)
────────────────────────────────────────────────────────────────
Alphabet size    64              64               32
Bits per char    6               6                5
Characters used  A-Z a-z 0-9     A-Z a-z 0-9      A-Z 2-7
                 + /             - _              (+ = for pad)
Padding          = (required)    = (optional)     = (optional)
Case-sensitive   Yes             Yes              No (A = a)
Size overhead    ~33%            ~33%             ~60%
URL-safe         No              Yes              Yes
Filename-safe    No              Yes              Yes
DNS-safe         No              Yes              Yes
Human-readable   Medium          Medium           High
Human-spoken     Painful         Painful          Doable
QR-code friendly OK              OK               Excellent
                 (alphanumeric)  (alphanumeric)   (alphanumeric mode)

// WAS SIE GEMEINSAM HABEN

Alle drei sind in RFC 4648 definiert — einem einzigen Dokument von 2006, das die Familie der "base-N Binary-to-Text-Kodierungen" zusammengeführt hat. Sie teilen sich denselben zugrundeliegenden Algorithmus: binäre Eingabe nehmen, die Bits in Stücke von log₂(Alphabetgröße) umgruppieren, jedes Stück auf ein Zeichen abbilden und auf die Ausgabewort-Grenze auffüllen.

• Base64: 6-Bit-Stücke → 4 Zeichen pro 3 Bytes (Verhältnis 4/3, ca. 33% größer)
• Base32: 5-Bit-Stücke → 8 Zeichen pro 5 Bytes (Verhältnis 8/5, ca. 60% größer)
• Base16 (hex): 4-Bit-Stücke → 2 Zeichen pro 1 Byte (Verhältnis 2/1, 100% größer)

Alle drei sind reversibel, deterministisch und bewahren jedes Byte der Eingabe. Es sind Kodierungen, keine Komprimierung und keine Verschlüsselung. Wer den String hat, kann ihn zurückrechnen.

// WANN BASE64 (STANDARD, §4) WÄHLEN

Standard-Base64 ist die Vorgabe für jeden Textkanal, der keine URL ist. MIME-E-Mail-Bodies, PEM-umhüllte Zertifikate, HTTP Basic Auth, S/MIME, XML-DSIG, Data-URIs und die meisten Binär-in-Text-Container von Dateiformaten nutzen es. Die Zeichen + / = sind alle sicher in quotierten Attributwerten, in E-Mail-Headern (bei Zeilenumbrüche) und in XML-/JSON-Strings.

Verwenden Sie Standard-Base64, wenn der nachgelagerte Konsument ein Textprotokoll ist, das beliebiges druckbares ASCII akzeptiert — insbesondere, wenn RFC-Spezifikationen es ausdrücklich vorschreiben (MIME: RFC 2045; PEM: RFC 7468; HTTP Basic Auth: RFC 7617; Data-URI: RFC 2397).

> E-Mail-Anhänge (MIME Base64 Transfer Encoding)
> PEM-Zertifikate, -Schlüssel, -CRLs (-----BEGIN ... -----)
> Wert im HTTP-Basic-Authentication-Header
> Data-URIs: data:image/png;base64,...
> S/MIME- und XML-ENC-Payloads
> Klassische SOAP- / XML-DSIG-Signaturen
> Beliebiges Binärfeld in einem JSON-Dokument, das nicht anschließend in eine URL wandert

// WANN BASE64URL (§5) WÄHLEN

In dem Moment, in dem Ihre Base64-Ausgabe eine URL, einen Cookie-Wert, einen Dateinamen, ein DNS-Label oder einen Ort berührt, an dem + / = prozentkodiert werden müssten, wechseln Sie zu Base64URL. Es verwendet dasselbe 64-Zeichen-Alphabet mit zwei Vertauschungen (+ → -, / → _) und lässt konventionell das Padding weg.

> JWT-Tokens — Header, Payload, Signatur sind allesamt base64url (RFC 7515)
> OAuth 2.0 PKCE code_challenge (RFC 7636)
> OpenID Connect state- und nonce-Parameter
> Magic Links, Einladungs-Tokens, Passwort-Reset-Tokens
> Cookie-Werte, die in URLs kopiert werden könnten
> Aus Hashes abgeleitete Dateinamen — vermeiden Sie / in Dateinamen
> DNS-Labels, TXT-Records — Bindestriche erlaubt, Schrägstriche nicht
> Schlüssel für inhaltsadressierte Speicher
> Kurze URL-IDs, erzeugt aus zufälligen Bytes

// WANN BASE32 (§6) WÄHLEN

Base32 verwendet nur 32 Zeichen: Großbuchstaben A–Z und die Ziffern 2–7. Das sind ca. 60% Größenoverhead — deutlich schlechter als Base64 —, doch Sie erhalten drei sehr spezifische Eigenschaften, die Base64 nicht bieten kann.

Unabhängigkeit von Groß-/Kleinschreibung. Das Alphabet ist rein groß. Menschen, die den String lesen oder tippen, können die Groß-/Kleinschreibung ignorieren; JBSWY3DP und jbswy3dp dekodieren identisch.

Eindeutige Zeichen. Die Ziffern 0, 1, 8 und 9 sind ausgeschlossen, da sie in gängigen Schriften O, I, B und g ähneln. Verwendet werden nur 2–7. Das macht die handschriftliche Übertragung von einer gedruckten Seite oder einem Handybildschirm deutlich zuverlässiger.

Alphanumeric-Mode-Kompatibilität für QR-Codes. QR-Codes verfügen über einen speziellen "Alphanumeric"-Modus, der mit einer ASCII-Teilmenge 5,5 Bit pro Zeichen kodiert. Base32 passt komplett in diese Teilmenge (plus Padding), sodass ein QR-kodierter Base32-String deutlich kleiner ist als ein QR-kodierter Base64-String.

> TOTP-/HOTP-Secret-Seeds — Google Authenticator, 1Password, Authy nutzen alle Base32
> Tor-.onion-v3-Adressen — 56-Zeichen-Base32-Kodierungen von ed25519-Schlüsseln
> BitTorrent-Info-Hashes, die als Magnet-Links geteilt werden
> Geohash-ähnliche, menschlich teilbare Ortscodes
> Lizenzschlüssel und Produkt-Seriennummern
> Gedruckte Recovery-Codes (2FA-Backup-Codes, Wallet-Mnemoniken)
> DTMF-ähnliche Übertragung über Sprachkanäle
> Systeme, die Speicherung unabhängig von Groß-/Kleinschreibung benötigen (DNS-Labels)

// GRÖSSEN-OVERHEAD — EIN KONKRETES BEISPIEL

// Input: a 32-byte SHA-256 hash
// Raw: 0x89abcdef…                             (32 bytes, binary — can't put in text)
// Hex (Base16): 40b2e2…                        (64 chars, 100% overhead)
// Base32:       5ENM4H2TQWMZ3O4OQBJAFY5Q       (56 chars, 75% overhead)
// Base64:       ia+N7/eZtRsPj5TqFoqUlD…        (44 chars, 37% overhead)
// Base64URL:    ia-N7_eZtRsPj5TqFoqUlD…        (43 chars, 34% overhead, no padding)

// Input: a 16-byte UUID
// Hex:       e7a6c1d0-4b7d-4c6c-8e2f-9f1a3e4b5c6d (36 chars incl. dashes)
// Base32:    5WTMDUCLPVGGZDRPTF…                  (26 chars)
// Base64:    56bB0Et9TGyOL58aPktcbQ==             (24 chars)
// Base64URL: 56bB0Et9TGyOL58aPktcbQ               (22 chars, no padding)

// BENCHMARK FÜR MENSCHLICHE LESBARKEIT

Hier glänzt Base32. Versuchen Sie, diese laut vorzulesen:

• a+b/c1D2e3F/+g= — Base64. "klein-a, plus, klein-b, Schrägstrich, klein-c, eins, groß-D, zwei, klein-e, drei, groß-F, Schrägstrich, plus, klein-g, Gleichheitszeichen." Allein die Groß-/Kleinschreibung ist fehleranfällig bei der Übertragung.

• JBSWY3DPEHPK3PXP — Base32. "J-B-S-W-Y, drei, D-P-E-H-P-K, drei, P-X-P." Groß-/Kleinschreibung spielt keine Rolle. Keine Verwechslung zwischen 0/O oder 1/l. Dies lässt sich am Telefon mit hoher Zuverlässigkeit weitergeben.

Genau deshalb verwendet TOTP Base32: jemand muss den Seed von einem QR-Code-Ausweichbildschirm in seine Authenticator-App tippen. Die Groß-/Kleinabhängigkeit von Base64 würde endlos viele Support-Tickets erzeugen.

// GRÖSSENVERGLEICH BEI QR-CODES

QR-Codes verfügen über einen speziellen "Alphanumeric-Mode", der 5,5 Bit pro Zeichen über eine 45-Zeichen-Teilmenge packt: 0–9, A–Z (nur Großbuchstaben), Leerzeichen und $ % * + - . / :. Alles außerhalb dieser Teilmenge zwingt den QR-Code in den "Byte Mode", der 8 Bit pro Zeichen nutzt — deutlich größere QR-Codes.

Base32 liegt vollständig innerhalb der Alphanumeric-Teilmenge. Base64 nicht — Kleinbuchstaben und +/= erzwingen den Byte Mode (zwar gehören +/ zum Alphanumeric-Set, doch jeder Kleinbuchstabe erzwingt Byte Mode). Das bedeutet, dass dieselbe Payload als Base32 in einen kleineren QR-Code passt als als Base64 — oft der Unterschied zwischen einem lesbaren 21×21-QR und einem überfüllten 33×33.

// STOLPERFALLEN BEIM DEKODIEREN

> Groß-/Kleinschreibung — Base64-Decoder lehnen falsch geschriebene Eingaben ab (SGVsbG8= ≠ sgvSbg8=). Base32-Decoder normieren vor dem Nachschlagen typischerweise auf Großbuchstaben und tolerieren daher beliebige Schreibweisen.
> Padding — Standard-Base64 verlangt =-Padding; JWT/base64url verbietet es; Base32 macht es optional (RFC 4648 §6). Prüfen Sie stets, was Ihr Decoder erwartet.
> Whitespace — MIME-Base64 wird bei 76 Spalten mit CR-LF umgebrochen. Viele Decoder tolerieren Whitespace, manche nicht. Vor der Übergabe an atob() oder äquivalent entfernen.
> Alphabet-Kollisionen — Base64 in einen Base32-Decoder zu füttern (oder umgekehrt) sieht zunächst so aus, als könnte es funktionieren — A, B, C sind in beiden gültig — und scheitert dann stillschweigend, sobald + oder = auftaucht.
> Crockford Base32 ist eine Nicht-RFC-Variante, die von Stripe-IDs und manchen Blockchain-Systemen verwendet wird. Sie nutzt ein anderes Alphabet (ohne I, L, O, U) und unterstützt Prüfziffern. Nicht mit RFC-4648-Base32 verwechseln.
> Base32 Extended Hex (RFC 4648 §7) — ein alternatives Base32-Alphabet, das die lexikografische Sortierreihenfolge erhält. Verwendet in DNSSEC-NSEC3-Records. Leicht mit Standard-Base32 zu verwechseln.

// EIN ENTSCHEIDUNGSFLUSSDIAGRAMM

Does the output go into a URL, cookie, filename, DNS, JWT, or OAuth flow?
│
├─ Yes  →  Does a human need to type or speak the string?
│         │
│         ├─ Yes  →  Base32 (uppercase, no ambiguous chars)
│         │         e.g., TOTP seeds, recovery codes
│         │
│         └─ No   →  Base64URL (more compact, URL-safe)
│                   e.g., JWT, short tokens, hash-named files
│
└─ No  →  Does the output go into a QR code that must stay tiny?
          │
          ├─ Yes  →  Base32 (fits in QR alphanumeric mode)
          │
          └─ No   →  Standard Base64
                    e.g., email MIME, PEM, HTTP Basic, data URI

// WARUM NICHT BASE16 (HEX)?

Hexadezimal (RFC 4648 §8 nennt es Base16) ist der universelle Rückfall. Jedes Shell-Tool, jeder Debugger und jedes Protokoll versteht es. Es ist unabhängig von Groß-/Kleinschreibung, trivial für Menschen lesbar und trivial zu implementieren. Doch es verdoppelt die Größe der Payload (100% Overhead), weshalb es nur für kleine, feste IDs genutzt wird: SHA-256-Hashes (64 Hex-Zeichen = 32 Bytes), UUIDs (32 Hex-Zeichen = 16 Bytes), MAC-Adressen, Speicheradressen in Debuggern.

Für alles, was größer als ein paar Dutzend Bytes ist, fällt der Größenaufschlag von Hex auf der Leitung echt ins Gewicht. Base64 ist 50% kleiner als Hex, Base32 ist 25% kleiner. Darum hat Base64 die Anwendungsfälle E-Mail und Web-Einbettung gewonnen, während Hex beim Debuggen und bei der Hash-Anzeige verblieb.

// WAS IST MIT BASE58 / BASE62 / BASE85?

Nicht-RFC-base-N-Kodierungen existieren für bestimmte Nischen:
• Base58 — Bitcoin-Adressen, Flickr-Foto-IDs. Schließt die vier mehrdeutigen Zeichen (0, O, I, l) sowie +/ aus, um die menschliche Übertragung zu vereinfachen. Ca. 37% Overhead.
• Base62 — URL-Shortener, Twitter-Snowflake-IDs. Verwendet nur Alphanumerische (keine Sonderzeichen), sicher in URLs ohne Escaping. Ca. 34% Overhead.
• Base85 / Ascii85 / Z85 — PostScript, PDF, ältere ZeroMQ-Frames. Ca. 25% Overhead (dichter als Base64), aber mit heiklen Zeichenwahlen, die XML-/JSON-Escape-Höllen verursachen können.

Das ist interessant, aber keine davon ist RFC-4648-standardisiert. Wenn Sie ein öffentliches Protokoll ausliefern, ist Base64 oder Base64URL fast immer die sicherere Vorgabe, weil die Standardbibliothek jeder Sprache sie bereits unterstützt. Wählen Sie Base58, liefern Sie jedem Konsumenten eine Abhängigkeit mit.

// NEBENEINANDER AUSPROBIEREN

• Base64-Encoder — Standardalphabet mit URL-sicherem Umschalter
• Base64URL-Encoder — URL-sicher ohne Padding
• Base32-Encoder — RFC 4648 §6-Alphabet
• Base16-(hex)-Encoder — zum Vergleich
• Base58-Encoder — Bitcoin-artiges, menschenfreundliches Alphabet

Weiterführende Lektüre:
• Was ist Base64 und wie funktioniert es?
• URL-sicher vs. Standard-Base64 — die ganze Geschichte
• Base64 für UTF-8 und Unicode