Warum genau 33 % größer, keine andere Zahl?

Base64 kodiert 3 Bytes (24 Bit) Eingabe als 4 Ausgabezeichen (je 6 Bit, da das Alphabet 64 Symbole hat). Das ist ein Verhältnis von 4:3, also exakt 33,3 % mehr Zeichen als Eingabe-Bytes — und da jedes Ausgabezeichen als ein Byte in einer Textdatei gespeichert wird, wächst die Datei selbst um rund ein Drittel.

Kann ich den 33-%-Overhead vermeiden?

Nur, indem Sie Base64 nicht nutzen — der Overhead ist dem Prinzip inhärent, beliebige Binärdaten als druckbaren ASCII-Text darzustellen. Zählt Größe mehr als die Vermeidung eines nicht binär-sicheren Transports, senden Sie die rohen Binärdaten direkt (z. B. Multipart-Formular-Uploads oder einen binären API-Body) statt sie in Base64 zu kodieren.

Hebt gzip-Kompression den Base64-Overhead auf?

Teilweise. Base64-Ausgabe lässt sich recht gut komprimieren, da ihr 64-Zeichen-Alphabet im Vergleich zu zufälligen Binärdaten klein und repetitiv ist, sodass gzip typischerweise einen Teil, aber nicht den gesamten verlorenen Boden zurückgewinnt — meist bleiben Sie trotzdem etwas größer als die rohen, mit gzip allein übertragenen Binärdaten.

Warum endet Base64-Ausgabe manchmal mit = oder == ?

Das ist Padding. Base64 gruppiert die Eingabe in Blöcken von 3 Bytes; ist die Eingabelänge kein Vielfaches von 3, wird die letzte Gruppe mit 1 oder 2 „=“-Zeichen aufgefüllt, damit die Ausgabelänge ein Vielfaches von 4 bleibt — was manche Decoder benötigen, um den String korrekt zu parsen.

Guide

Warum Base64 Dateien rund 33 % größer macht

Es ist kein Fehler oder eine ineffiziente Implementierung — der 33-%-Overhead ist fest eingebaut in das, was Base64 tut.

By Buğra SözeriPublished September 25, 2026

Base64 komprimiert nichts — es bewirkt das Gegenteil. Es existiert, um Binärdaten sicher durch reine Textkanäle (E-Mail-Inhalte, JSON-Strings, XML, URLs) zu transportieren, die nie dafür entworfen wurden, rohe Bytes zu handhaben, und diese Sicherheit kostet Platz: Aus jeweils 3 Bytes Eingabe werden 4 Zeichen Ausgabe, ein festes Verhältnis von 4:3, was rund 33 % größer als das Original ergibt, unabhängig davon, um welche Daten es sich tatsächlich handelt.

Die Rechnung hinter den 33 %

Base64s Alphabet hat 64 Symbole (A–Z, a–z, 0–9, plus zwei weitere Zeichen, typischerweise + und /), und 64 = 2⁶, sodass jedes Ausgabezeichen genau 6 Bit kodiert. Drei Bytes Eingabe sind 24 Bit, die sich gleichmäßig in vier 6-Bit-Gruppen aufteilen — daher werden aus 3 Eingabe-Bytes 4 Ausgabezeichen. Da jedes Zeichen dann als ein Byte Text gespeichert wird, werden aus 3 Bytes Binärdaten 4 Bytes Base64-Text: ein Faktor von 4/3 ≈ 1,333, oder ein Größenzuwachs von 33,3 %. Das ist nicht implementierungsspezifisch — es ist so in RFC 4648 definiert, dem IETF-Standard, dem jeder Base64-Encoder folgt.

Padding: das zusätzliche Bit

Eingabelänge (Bytes)	Kodierte Länge	Padding
Vielfaches von 3 (z. B. 3, 6, 9…)	Exaktes 4/3-Verhältnis	Keines
Rest 1 (z. B. 1, 4, 7…)	Rundet auf zur nächsten 4er-Gruppe	`==`
Rest 2 (z. B. 2, 5, 8…)	Rundet auf zur nächsten 4er-Gruppe	`=`

Ist die Eingabelänge kein sauberes Vielfaches von 3, wird die letzte Gruppe mit einem oder zwei =-Zeichen aufgefüllt, damit die gesamte Ausgabelänge ein Vielfaches von 4 bleibt — manche Decoder benötigen das, um den String korrekt zu parsen, auch wenn es technisch redundante Information ist. Bei kleinen Eingaben kann das Padding den Overhead leicht über 33 % treiben, aber der Effekt schrumpft mit größerer Eingabe Richtung der theoretischen 33,3 %.

Wann sich der Overhead lohnt

Die 33-%-Kosten kaufen Kompatibilität: Base64-Ausgabe ist reines ASCII, übersteht also das Einfügen in einen JSON-String, ein XML-Attribut, einen URL-Query-Parameter oder einen E-Mail-Inhalt ohne Beschädigung — nichts davon kann rohe Binär-Bytes sicher aufnehmen. Das ist der Kompromiss hinter dem Einbetten kleiner Bilder als Data-URIs oder dem Anhängen von Dateien an eine E-Mail. Für wirklich große Dateien, oder wo bereits ein binär-sicherer Transport existiert (ein Datei-Upload-Endpunkt, Multipart-Formulardaten, eine Object-Storage-API), vermeidet der Verzicht auf Base64 zugunsten der rohen Bytes den Overhead vollständig — siehe das Base64-Werkzeug, wenn Sie genau prüfen möchten, wie groß eine bestimmte Datei wird, bevor Sie sich für die Kodierung entscheiden.

Frequently asked questions

Warum genau 33 % größer, keine andere Zahl?: Base64 kodiert 3 Bytes (24 Bit) Eingabe als 4 Ausgabezeichen (je 6 Bit, da das Alphabet 64 Symbole hat). Das ist ein Verhältnis von 4:3, also exakt 33,3 % mehr Zeichen als Eingabe-Bytes — und da jedes Ausgabezeichen als ein Byte in einer Textdatei gespeichert wird, wächst die Datei selbst um rund ein Drittel.
Kann ich den 33-%-Overhead vermeiden?: Nur, indem Sie Base64 nicht nutzen — der Overhead ist dem Prinzip inhärent, beliebige Binärdaten als druckbaren ASCII-Text darzustellen. Zählt Größe mehr als die Vermeidung eines nicht binär-sicheren Transports, senden Sie die rohen Binärdaten direkt (z. B. Multipart-Formular-Uploads oder einen binären API-Body) statt sie in Base64 zu kodieren.
Hebt gzip-Kompression den Base64-Overhead auf?: Teilweise. Base64-Ausgabe lässt sich recht gut komprimieren, da ihr 64-Zeichen-Alphabet im Vergleich zu zufälligen Binärdaten klein und repetitiv ist, sodass gzip typischerweise einen Teil, aber nicht den gesamten verlorenen Boden zurückgewinnt — meist bleiben Sie trotzdem etwas größer als die rohen, mit gzip allein übertragenen Binärdaten.
Warum endet Base64-Ausgabe manchmal mit = oder == ?: Das ist Padding. Base64 gruppiert die Eingabe in Blöcken von 3 Bytes; ist die Eingabelänge kein Vielfaches von 3, wird die letzte Gruppe mit 1 oder 2 „=“-Zeichen aufgefüllt, damit die Ausgabelänge ein Vielfaches von 4 bleibt — was manche Decoder benötigen, um den String korrekt zu parsen.

Sources & references

Authoritative references cited by this piece. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

RFC 4648 — The Base16, Base32, and Base64 Data Encodings — Der IETF-Standard, der das Base64-Alphabet, das Padding und die 3-Byte-zu-4-Zeichen-Gruppierung definiert(as of 2026-09-25)
MDN — Base64 encoding and decoding — MDNs Erklärung von Base64s Binär-zu-Text-Zweck und Größen-Overhead(as of 2026-09-25)

Published September 25, 2026