Base64-Kodierung erklärt: Wann und warum man sie verwendet

Sie haben Base64 bestimmt schon gesehen — diese langen, merkwürdigen Zeichenketten wie SGVsbG8gV29ybGQ=. Sie tauchen in E-Mails, Data-URIs, API-Payloads und JWTs auf. Aber was ist Base64 eigentlich, und wann sollte man es verwenden? Lassen Sie uns das Geheimnis lüften.

Was Base64 macht (einfach erklärt)

Base64 nimmt beliebige Daten — Text, Bilder, Dateien, was auch immer — und wandelt sie in eine Zeichenkette um, die nur 64 „sichere" ASCII-Zeichen verwendet: A-Z, a-z, 0-9, + und /. Das = am Ende ist Padding.

Warum? Weil nicht jedes System rohe Binärdaten verarbeiten kann. E-Mail wurde für Text entwickelt. JSON unterstützt kein Binärformat. URL-Parameter können keine beliebigen Bytes enthalten. Base64 ist die Brücke, die Binärdaten durch reine Textkanäle transportiert.

Wie es unter der Haube funktioniert

Der Algorithmus ist überraschend einfach. Er nimmt 3 Bytes Eingabe (24 Bits), teilt sie in 4 Gruppen zu je 6 Bits auf und ordnet jede Gruppe einem der 64 Zeichen zu. Hier ein kurzes Beispiel:

Eingabe: Hi (2 Bytes: 72, 105)

Binär: 01001000 01101001 + Padding-Nullen

Aufgeteilt in 6-Bit-Gruppen: 010010 000110 100100

Zugeordnet zum Base64-Alphabet: SGk=

Die Mathematik bedeutet, dass die Base64-Ausgabe immer etwa 33% größer ist als die Eingabe. Das ist der Kompromiss für sichere Textübertragung. Die RFC 4648-Spezifikation definiert den genauen Algorithmus, falls Sie es ganz genau wissen wollen.

Wann Sie Base64 verwenden sollten

Kleine Bilder in HTML/CSS einbetten: Statt den Browser eine separate Datei laden zu lassen, können Sie ein kleines Icon inline einbinden: . Das spart einen HTTP-Request. Ideal für Icons unter 2-3KB.

Binärdaten in JSON-APIs senden: JSON kann keine rohen Bytes speichern. Müssen Sie eine Datei über eine JSON-API hochladen? Base64-kodieren Sie sie:

E-Mail-Anhänge: Genau dafür wurde Base64 ursprünglich entwickelt. Die MIME-Kodierung nutzt Base64, um binäre Anhänge in textbasierte E-Mail-Nachrichten einzubetten.

JWTs und Auth-Tokens: JSON Web Tokens verwenden Base64URL-Kodierung (eine URL-sichere Variante) für ihre Header- und Payload-Abschnitte.

Binärdaten in Textfeldern speichern: Datenbank-Textspalten, Umgebungsvariablen, Konfigurationsdateien — Base64 ermöglicht es, Binärdaten überall dort unterzubringen, wo Text hingehört.

Wann Sie Base64 NICHT verwenden sollten

• Große Dateien. Die 33% Größenzunahme tut bei großen Dateien richtig weh. Ein 10MB-Bild wird zu 13,3MB in Base64. Verwenden Sie stattdessen Multipart-Form-Upload.
• Sicherheit. Base64 ist keine Verschlüsselung. Es ist trivial umkehrbar. Verwenden Sie es niemals, um Passwörter oder sensible Daten zu „verstecken". Jeder kann cGFzc3dvcmQ= in Sekunden zurück zu password dekodieren.
• Große Inline-Bilder. Für Bilder über ~5KB ist eine separate Datei mit ordentlichem HTTP-Caching performanter als eine Base64-Data-URI.

Die URL-sichere Variante

Standard-Base64 verwendet + und /, die in URLs eine besondere Bedeutung haben. Die Base64URL-Variante ersetzt sie durch - und _. Sie werden das in JWTs und überall dort sehen, wo Base64-Daten in URLs vorkommen.

Schnelle Code-Beispiele

So kodieren und dekodieren Sie Base64 in den gängigsten Sprachen:

Beachten Sie, dass die Browser-Funktion btoa() in JavaScript nur mit ASCII-Zeichenketten funktioniert. Wenn Sie Unicode-Text kodieren müssen, brauchen Sie einen zusätzlichen Schritt über TextEncoder — daran scheitern viele Entwickler.

Häufige Fehler mit Base64

Hier sind die Stolperfallen, die ich bei Entwicklern am häufigsten sehe:

1. Annahme, dass Base64 Verschlüsselung ist. Ich kann das nicht oft genug betonen. Ich habe Produktiv-Codebasen gesehen, die API-Keys und Passwörter Base64-kodieren und denken, sie wären „geschützt". Jeder mit einer Browser-Konsole kann sie sofort dekodieren. Wenn Sie Daten schützen müssen, verwenden Sie echte Verschlüsselung (AES, RSA) oder Hashing (bcrypt, argon2).

2. Padding nicht korrekt behandeln. Manche Implementierungen entfernen die abschließenden =-Zeichen, was bei strikten Parsern zu Dekodierungsfehlern führen kann. Wenn Sie Base64 zwischen Systemen austauschen, einigen Sie sich darauf, ob Padding enthalten ist oder nicht.

3. Standard-Base64 in URLs verwenden. Die Zeichen + und / im Standard-Base64 werden URLs kaputtmachen. Verwenden Sie immer die URL-sichere Variante (Base64URL), wenn Sie kodierte Daten in Query-Parameter oder Pfadsegmente einbetten.

4. Große Dateien in JSON-Payloads Base64-kodieren. Eine 5MB-Datei wird nach Base64-Kodierung fast 7MB groß, und dieser gesamte String muss im Speicher gehalten werden. Für alles, was größer als ein paar KB ist, verwenden Sie stattdessen multipart/form-data.

Base64-Zeichensatz Kurzreferenz

Praxisbeispiel: Schriftarten in CSS einbetten

Ein häufiger Einsatz von Base64, an den man vielleicht nicht sofort denkt, ist das direkte Einbetten von Schriftarten in CSS-Dateien. Das spart einen zusätzlichen HTTP-Request für die Schriftdatei:

Diese Technik funktioniert gut für kleine Icon-Schriftarten (unter 10-15KB). Für größere Schriftdateien ist es besser, sie separat auszuliefern, damit der Browser sie unabhängig cachen kann.

Base64 vs. andere Kodierungsverfahren

Base64 ist nicht die einzige Möglichkeit, Binärdaten als Text darzustellen. Es gibt mehrere Alternativen, und jede hat ihren Sweet Spot. Vergleichen wir die wichtigsten.

Hex-Kodierung (Base16): Der einfachste Ansatz — jedes Byte wird zu zwei Hex-Zeichen (0-9, A-F). So wird Hi zu 4869. Es ist simpel und menschenlesbar, aber die Ausgabe ist 100% größer als die Eingabe (doppelte Größe). Hex sieht man überall: Farbcodes (#FF5733), SHA-Hashes, MAC-Adressen und Debug-Ausgaben.

Base32: Verwendet 32 Zeichen (A-Z und 2-7). Die Ausgabe ist etwa 60% größer als die Eingabe. Sie haben es wahrscheinlich schon gesehen, ohne es zu merken — die 6-stelligen Codes von Google Authenticator und anderen TOTP/2FA-Apps verwenden im Hintergrund Base32-kodierte Geheimnisse. Es ist auch Groß-/Kleinschreibung-unabhängig, was es ideal macht, wenn Benutzer die kodierten Daten manuell eingeben müssen.

ASCII85 / Base85: Verwendet 85 druckbare ASCII-Zeichen und erzeugt eine Ausgabe, die nur etwa 25% größer als die Eingabe ist. Das ist effizienter als Base64. Git verwendet eine Variante von Base85 in seinem binären Patch-Format (Packfiles), und Adobe PostScript sowie PDF-Dateien verwenden intern ASCII85-Kodierung. Der Nachteil? Es verwendet Zeichen wie {, } und Anführungszeichen, die in JSON, XML und URLs Kopfschmerzen bereiten können.

Hier ein Vergleich bei der Kodierung derselben 100-Byte-Eingabe:

Warum gewinnt Base64 in den meisten Fällen? Es trifft den Sweet Spot: angemessener Overhead, breite Unterstützung in jeder Sprache und Plattform, und es vermeidet die meisten Sonderzeichen, die in gängigen Formaten Probleme verursachen. Base85 ist kompakter, aber weniger universell unterstützt und schwieriger sicher in strukturierten Textformaten zu verwenden.

Base64 in Authentifizierungs-Abläufen

Einer der am weitesten verbreiteten (und am meisten missverstandenen) Einsätze von Base64 ist die HTTP Basic Authentication. Wenn Sie einen Benutzernamen und ein Passwort über Basic Auth senden, verkettet der Browser sie mit einem Doppelpunkt und Base64-kodiert das Ergebnis.

Folgendes passiert im Hintergrund, wenn Sie sich mit Benutzername admin und Passwort secret123 anmelden:

Der Server empfängt diesen Header, dekodiert ihn mit Base64, trennt am Doppelpunkt und prüft die Anmeldedaten. Einfach, oder? Aber hier ist der entscheidende Punkt: Das ist NICHT sicher ohne HTTPS. Dieser Base64-String ist trivial umkehrbar — jeder, der die Anfrage abfängt, kann YWRtaW46c2VjcmV0MTIz dekodieren und Ihr Passwort in unter einer Sekunde erhalten. Die RFC 7617-Spezifikation für Basic Auth warnt ausdrücklich davor.

Base64 taucht auch in anderen Auth-Kontexten auf. OAuth 2.0 Access-Tokens und Refresh-Tokens sind oft Base64-kodiert (obwohl das ein Implementierungsdetail ist, keine Anforderung). Viele API-Keys von Diensten wie AWS, Stripe und Google Cloud sind Base64-kodierte Strings. Auch hier gilt: Die Kodierung dient dem sicheren Transport — nicht der Sicherheit. Senden Sie diese immer über HTTPS und speichern Sie sie sicher.

Data-URIs im Detail

Wir haben Data-URIs kurz erwähnt, aber sie verdienen einen genaueren Blick. Eine Data-URI ermöglicht es, Dateiinhalte direkt in HTML, CSS oder JavaScript einzubetten — kein externer HTTP-Request nötig. Die vollständige Syntax lautet:

Der mediatype ist ein Standard-MIME-Typ, das ;base64-Flag teilt dem Browser mit, dass die Daten Base64-kodiert sind (ohne es werden URL-kodierte Textdaten angenommen), und ist der eigentliche Inhalt.

Hier sind Beispiele für verschiedene Medientypen:

PNG-Bild (am häufigsten):

Inline-SVG (kein Base64 nötig!):

Beachten Sie, dass SVGs bereits Text sind, sodass Sie sie URL-kodieren können, anstatt sie Base64-zu-kodieren. Das ist tatsächlich kleiner, weil Sie den 33%-Overhead überspringen. Clevere Entwickler nutzen diesen Trick für einfache SVG-Icons.

PDF-Dokument:

Audiodatei:

Nun zu den Browser-Limits. Obwohl die Data-URI-Spezifikation auf MDN keine maximale Größe definiert, setzen Browser ihre eigenen Limits. Chrome begrenzt Data-URIs in Navigations-Kontexten (wie iframes und Top-Level-Seiten) auf etwa 2MB. Firefox ist großzügiger. Für CSS-Hintergrundbilder und Inline-Bilder ist das praktische Limit die Geduld Ihrer Nutzer — ein 500KB Base64-String in Ihrer CSS-Datei ist technisch gültig, wird aber die Ladezeiten absolut ruinieren.

Performance-Auswirkung: Wenn Base64 schadet

Sprechen wir über echte Zahlen, denn „33% Overhead" klingt abstrakt, bis man die Auswirkung in der Praxis sieht.

Bandbreitenkosten: Ein 50KB-Bild wird nach Base64-Kodierung ~67KB groß. Das sind 17KB extra pro Bild. Multiplizieren Sie das mit 20 Inline-Icons auf einer Seite und Sie senden 340KB unnötige Daten. Zum Vergleich: Das ist mehr als das gesamte HTML der meisten Webseiten.

Speicherverbrauch: Wenn Sie ein Bild Base64-kodieren und in HTML oder CSS einbetten, muss der gesamte kodierte String als Teil des DOM oder Stylesheets im Speicher gehalten werden. Der Browser dekodiert ihn dann zurück in Binärdaten, sodass Sie kurzzeitig sowohl die kodierte als auch die dekodierte Version halten. Bei einem 1MB-Bild sind das etwa 2,33MB nur für den kodierten String, plus 1MB für die dekodierten Binärdaten — über 3x die ursprüngliche Dateigröße.

Parse-Zeit: Base64-Strings in HTML oder CSS müssen als Teil dieser Dokumente geparst werden. Eine große Data-URI macht das gesamte CSS- oder HTML-Dokument langsamer beim Parsen. Laut dem Image-Optimization-Leitfaden von web.dev sollten Inline-Bilder generell unter 2-4KB liegen, um einen Netto-Performance-Vorteil zu bieten.

Cache-Ineffizienz: Das ist der Punkt, den die meisten Entwickler übersehen. Wenn Sie ein Bild als separate Datei ausliefern, cached der Browser es unabhängig — nachfolgende Seitenaufrufe überspringen den Download komplett. Aber wenn Sie dasselbe Bild Base64-kodiert in Ihre CSS-Datei einbetten, wird es Teil des CSS. Wenn Sie irgendetwas anderes im CSS ändern, lädt der Browser die gesamte Datei neu herunter, einschließlich der Base64-Bilddaten, die sich nicht geändert haben. Sie verlieren granulares Caching.

Hier ein grober Benchmark zur Einordnung:

Die Faustregel: Base64-Inline für alles unter 2-4KB. Alles andere als separate Datei ausliefern. Mit HTTP/2 und HTTP/3 sind die Kosten für zusätzliche Requests minimal, sodass die Schwelle über die Jahre sogar niedriger geworden ist.

Base64 in verschiedenen Programmiersprachen

Wir haben JavaScript und Python bereits behandelt. So funktioniert Base64 in anderen beliebten Sprachen — jeweils nur ein paar Zeilen:

Beachten Sie, dass jede Sprache Base64 in ihrer Standardbibliothek hat — keine Drittanbieter-Pakete nötig. Das zeigt, wie grundlegend diese Kodierung ist. Außerdem hat Ruby strict_encode64 (keine Zeilenumbrüche) und encode64 (fügt alle 60 Zeichen Zeilenumbrüche ein, entsprechend dem ursprünglichen MIME-Standard). Für die meisten modernen Anwendungen will man die strikte Version.

Die Geschichte von Base64

Base64 ist nicht aus dem Nichts entstanden. Seine Geschichte ist eng mit der Geschichte der E-Mail verbunden, und das Verständnis erklärt viele der Designentscheidungen.

In den frühen Tagen des Internets war E-Mail (SMTP) dafür ausgelegt, nur 7-Bit-ASCII-Text zu verarbeiten — 128 Zeichen, und das war's. Das war für englischen Text in Ordnung, aber völlig unbrauchbar zum Versenden von Bildern, Dokumenten oder sogar Text in nicht-englischen Sprachen. Man konnte schlicht keine Binärdaten per E-Mail versenden.

Die erste formale Spezifikation von Base64 erschien in RFC 1421 im Jahr 1993, als Teil des Privacy Enhanced Mail (PEM) Standards. Die Idee war unkompliziert: Binärdaten in eine Teilmenge von ASCII umwandeln, die jedes textbasierte Transportsystem ohne Verfälschung übersteht.

Dann kam RFC 2045 im Jahr 1996, der MIME (Multipurpose Internet Mail Extensions) definierte. MIME standardisierte, wie E-Mail-Anhänge funktionieren, und Base64 war die primäre Kodierung für binäre Inhalte. Deshalb sehen Sie heute noch Content-Transfer-Encoding: base64-Header in rohen E-Mail-Nachrichten.

Die Kodierung wurde in RFC 4648 (2006) erneut verfeinert, die zur endgültigen Referenz wurde. Dieser RFC führte auch die URL-sichere Variante (Base64URL) ein und klärte Grenzfälle beim Padding. Die MDN Base64-Glossarseite ist ein guter Einstiegspunkt, wenn Sie die Spezifikation erkunden möchten, ohne rohe RFCs zu lesen.

Was faszinierend ist: Base64 wurde aus einer Einschränkung geboren — 7-Bit-E-Mail —, die nicht mehr existiert. Modernes SMTP unterstützt 8-Bit- und Binärübertragung. Dennoch hat Base64 seinen ursprünglichen Zweck weit überlebt und findet neues Leben in Web-APIs, JWTs, Data-URIs und zahllosen anderen Kontexten. Es ist eine jener Technologien, die ein Problem so gut gelöst haben, dass die Leute immer neue Probleme dafür finden.

Probieren Sie es selbst aus

Möchten Sie Base64 in Aktion sehen? Fügen Sie beliebigen Text oder eine Datei in unseren Base64 Encoder ein, um die kodierte Ausgabe sofort zu sehen. Müssen Sie etwas dekodieren? Der Base64 Decoder erledigt das. Und wenn Sie mit Base64-kodierten Bildern arbeiten, können Sie diese mit unserem Base64 to Image-Tool direkt im Browser als Vorschau anzeigen.