Base64-Encoder und -Decoder

So funktioniert der Base64-Encoder und -Decoder

Das Base64-Tool wandelt in beide Richtungen: Text in Base64 kodieren, mit UTF-8, so dass Umlaute, ß und Eurozeichen sauber durchkommen, oder eine Base64-Zeichenkette in Text dekodieren. Dazu zeigt es die Zahl der Zeichen und Bytes im Original, die Länge des Base64-Strings und wie viel größer er ist, und warnt, wenn das dekodierte Ergebnis nach Binärdaten statt nach Text aussieht. Das Ergebnis lässt sich mit einem Klick kopieren, für Basic-Auth-Header, Data-URLs, E-Mail-Anhänge, API-Schlüssel und die Frage, was in der komischen Zeichenkette im Log steht.

Merksatz: Base64 ist keine Verschlüsselung, sondern eine Verpackung, die aus beliebigen Bytes druckbare Zeichen macht, und jeder kann sie zurückwandeln. Die Eselsbrücke: Drei Bytes werden vier Zeichen, deshalb ein Drittel größer, und das Gleichheitszeichen am Ende ist Füllmaterial.

Drei Beispiele:

• "SGFsbG8gV2VsdCE=" dekodiert: "Hallo Welt!", 11 Zeichen Klartext.
• "Benutzer:Passwort123" kodiert: "QmVudXR6ZXI6UGFzc3dvcnQxMjM=", 20 Bytes werden 28 Zeichen, 40 Prozent größer, das Format des HTTP-Basic-Auth-Headers.
• "Hallo Welt! Umlaute wie ä, ö, ü und € funktionieren auch." kodiert: 57 Zeichen, aber 62 Bytes, weil Umlaute in UTF-8 zwei und das Eurozeichen drei Bytes brauchen, ergibt 84 Zeichen Base64, 35 Prozent größer.

Regeln statt Formeln: 3 Bytes → 4 Zeichen aus A-Z, a-z, 0-9, + und /, Rest mit = aufgefüllt, Länge = 4 × aufgerundet(Bytes / 3), Zuwachs ≈ 33 %. Für Adressen mit Sonderzeichen ist nicht Base64, sondern die Prozentkodierung zuständig, die der URL-Encoder erledigt, und wer eine Prüfsumme statt einer Verpackung braucht, nimmt den Hash-Generator.

Wissenswertes zum Thema

Wie Base64 funktioniert: Aus 8 Bit werden 6

Computer speichern alles in Bytes mit 256 möglichen Werten, aber viele Transportwege, E-Mail, alte Protokolle, Textfelder, XML, JSON, vertragen nur druckbare Zeichen; Base64 löst das, indem es den Bytestrom in Gruppen zu 24 Bit nimmt, drei Bytes, und sie in vier Gruppen zu 6 Bit zerlegt, von denen jede einen Wert von 0 bis 63 hat und einem Zeichen aus dem Alphabet A bis Z, a bis z, 0 bis 9, Plus und Schrägstrich entspricht. "Hal" wird so zu "SGFs": H ist 72, a 97, l 108, zusammen 24 Bit, in Sechsergruppen 18, 6, 5, 44, und das sind S, G, F, s. Bleiben am Ende ein oder zwei Bytes übrig, füllt der Kodierer mit Nullbits auf und hängt ein oder zwei Gleichheitszeichen an, "Hallo Welt!" hat 11 Bytes, 3 Dreiergruppen und 2 Rest, deshalb "SGFsbG8gV2VsdCE=" mit einem Gleichheitszeichen und 16 Zeichen. Der Preis ist die Größe, vier Zeichen für drei Bytes sind 33 Prozent mehr, bei kurzen Texten durch das Auffüllen auch 40, und ein Bild mit 100 Kilobyte wird als Base64 zu 133. Das Tool kodiert Text vorher als UTF-8, damit "ä" zu den zwei Bytes C3 A4 wird, die jeder Empfänger zurücklesen kann; wer Base64 aus einem anderen System dekodiert und Zeichensalat statt Umlauten sieht, hat einen Text, der in Latin-1 kodiert wurde. Was die Bytes eines Textes in Kilobyte und Megabyte ausmachen, rechnet der Datenmengen-Umrechner.

Wo Base64 überall steckt

Der E-Mail-Anhang ist der Klassiker: SMTP wurde 1982 für 7-Bit-Text entworfen, und MIME packt seit 1992 jedes Bild und jede PDF als Base64 in die Mail, deshalb ist ein 10-Megabyte-Anhang 13,3 Megabyte groß, und deshalb kennen Mailserver Größenlimits, die kleiner klingen als sie sind. Im Web stecken kleine Bilder und Schriften als Data-URL direkt in CSS und HTML, "data:image/png;base64,iVBORw0KGgo…", das spart einen Request, kostet aber ein Drittel Größe und lohnt nur unter zwei Kilobyte. Der HTTP-Header für Basic Auth ist "Authorization: Basic " plus Base64 von "Benutzer:Passwort", und wer das im Log liest, hat das Passwort, der Grund, warum Basic Auth nur über HTTPS geht. JSON Web Tokens bestehen aus drei Base64-Teilen, Header, Nutzdaten, Signatur, durch Punkte getrennt, und die Nutzdaten kann jeder lesen, nur die Signatur schützt vor Änderung. API-Schlüssel, Zertifikate im PEM-Format zwischen "-----BEGIN CERTIFICATE-----" und dem Ende, SSH-Schlüssel, Kubernetes-Secrets, Binärfelder in XML und JSON, Captcha-Bilder, QR-Codes in E-Mails, alles Base64. Die URL-sichere Variante ersetzt Plus und Schrägstrich durch Minus und Unterstrich und lässt die Gleichheitszeichen weg, weil die drei in Adressen stören; das Tool nutzt das Standardalphabet, und für Adressen gibt es die Prozentkodierung des URL-Encoders. Base32 und Base58 sind Verwandte für Fälle, in denen Groß- und Kleinschreibung oder verwechselbare Zeichen stören, Base58 steckt in Bitcoin-Adressen.

Was Base64 nicht ist und typische Fehler

Der wichtigste Irrtum ist die Verschlüsselung: Base64 verbirgt nichts, es sieht nur so aus, und ein Passwort in Base64 in einer Konfigurationsdatei ist ein Passwort im Klartext für jeden, der das Tool kennt; wer Geheimnisse schützen will, braucht Verschlüsselung, und wer Integrität prüfen will, einen Hash. Der zweite Fehler ist die doppelte Kodierung, ein bereits kodierter String wird noch einmal kodiert und beim Dekodieren kommt Base64 statt Text heraus, erkennbar an den vielen Großbuchstaben und dem Gleichheitszeichen im Ergebnis. Der dritte sind Zeilenumbrüche: MIME bricht Base64 alle 76 Zeichen um, PEM alle 64, und das Tool entfernt Leerzeichen und Umbrüche vor dem Dekodieren, andere Programme nicht. Der vierte ist das Zeichenset, Base64 von Latin-1-Text ergibt bei UTF-8-Dekodierung Fragezeichen oder Fehler, und das Tool arbeitet durchgehend in UTF-8. Der fünfte ist das fehlende Padding, manche Systeme lassen die Gleichheitszeichen weg, und strenge Dekodierer verweigern dann; die Länge muss durch 4 teilbar sein. Der sechste ist das Dekodieren von Binärdaten als Text: Beginnt das Ergebnis mit "PNG", "JFIF" oder "%PDF", war es eine Datei, und das Tool warnt bei Steuerzeichen am Anfang. Für die Prüfung, ob eine Datei unverändert angekommen ist, berechnet der Hash-Generator SHA-256 über den Inhalt.

Ein Stück Geschichte: Von uuencode zu RFC 4648

Das Problem ist so alt wie die Netze: Die ersten Mailsysteme der 1970er übertrugen 7-Bit-ASCII, und wer ein Programm verschicken wollte, musste es in Text verwandeln; Mary Ann Horton schrieb 1980 für Unix das Werkzeug uuencode, Unix-to-Unix-Encode, das dasselbe Prinzip nutzte, drei Bytes in vier Zeichen, aber mit einem Alphabet ab dem Leerzeichen, das in der Praxis ständig von Mailservern zerschossen wurde. Base64 mit dem heutigen Alphabet erschien 1987 in RFC 989 für die Verschlüsselung von Mails, Privacy Enhanced Mail, und wurde 1992 durch MIME in RFC 1421 und 1521 zum Standard für Anhänge, als Nathaniel Borenstein und Ned Freed das Mailformat um Multimedia erweiterten; Borenstein verschickte am 11. März 1992 als Test ein Foto seiner Barbershop-Gruppe, den ersten MIME-Anhang. RFC 2045 schrieb 1996 die Zeilenlänge von 76 Zeichen fest, RFC 4648 fasste 2006 Base64, die URL-sichere Variante, Base32 und Base16 zusammen und gilt bis heute. Die Data-URL kam 1998 mit RFC 2397 und wurde erst mit CSS-Sprites und mobilen Seiten um 2010 verbreitet, JSON Web Tokens 2015 mit RFC 7519. Die Funktionen btoa und atob, mit denen jeder Browser kodiert und dekodiert, stammen noch aus Netscape 2 von 1995 und heißen "binary to ASCII" und zurück, und sie sind der Grund, warum das Tool ohne Server auskommt. Die Verpackung, die Horton 1980 für Programme erfand, trägt heute jedes Foto in jeder Mail.

Praktische Tipps

Nutzen Sie Base64 zum Transportieren, nie zum Schützen. Dekodieren Sie unbekannte Zeichenketten aus Logs und Konfigurationen, bevor Sie sie weitergeben, oft stehen Passwörter drin. Rechnen Sie bei Anhängen und Data-URLs ein Drittel Größe dazu. Kodieren Sie Texte als UTF-8, sonst gehen Umlaute kaputt. Prüfen Sie bei Fehlern die Länge, durch 4 teilbar, und die Zeichen, nur A bis Z, a bis z, 0 bis 9, Plus, Schrägstrich. Nehmen Sie für URLs die Prozentkodierung oder Base64url. Und wenn das Ergebnis mit PNG oder %PDF beginnt, speichern Sie es als Datei statt als Text. Zufällige Schlüssel, die oft Base64-kodiert weitergegeben werden, erzeugt der Passwort-Generator.