Warum macht Base64 Dateien größer?

Dieser Artikel erklärt, warum Base64-Ausgabe größer ist als die Original-Bytes. Es ist kein Sicherheitsleitfaden. Brauchst du Kodierung versus Verschlüsselung, nutze Base64 ist keine Verschlüsselung: Was es wirklich tut.

Warum braucht Base64 mehr Platz?

3 Bytes sind 24 Bits. Base64 teilt diese 24 Bits in 4 Gruppen zu 6 Bits. Jede Gruppe wird ein Base64-Zeichen, also werden 3 Eingabe-Bytes zu 4 Ausgabezeichen. Als 1 Byte je ASCII-Zeichen gespeichert ist das 4 / 3 ≈ 1.333 — etwa 33.3% Zuwachs.

• 3 Bytes (24 Bits)
• ↓
• In 4 Gruppen zu 6 Bits teilen
• Jede Gruppe → ein Base64-Zeichen
• ↓
• 4 Zeichen (oft 4 Bytes Text)

Ein einfaches, prüfbares Beispiel

Diese Kodierungen entsprechen Standard-Base64 mit Padding.

Man

Man

Base64

TWFu

Man sind 3 UTF-8/ASCII-Bytes. TWFu sind 4 Zeichen: 3 → 4.

Hello

Hello

Base64

SGVsbG8=

Hello sind 5 Bytes. SGVsbG8= sind 8 Zeichen, inklusive eines =. Bei kleinen Daten lässt Padding den Prozentsatz größer als 33% wirken.

Wie berechnet man die Base64-Größe?

Für Standard-Base64 mit Padding gilt encodedLength = 4 × ceil(originalBytes / 3).

Original-Bytes	Base64-Zeichen
1	4
2	4
3	4
4	8
5	8
6	8

1 oder 2 Bytes ergeben trotzdem 4 Zeichen. Nimm die Formel, nicht ein festes 33%.

Was bedeutet das „=“-Padding?

Das =-Zeichen zeigt, dass der letzte 3-Byte-Block nicht voll war. 1 Eingabe-Byte nutzt zwei =-Zeichen; 2 Bytes eines; 3 Bytes keines. Padding ist keine Verschlüsselung und kein Sicherheitsmerkmal.

Nutzt Base64URL weniger Platz?

Base64URL ändert + zu - und / zu _, und Base64 kodieren und dekodieren lässt nachgestellte = beim Kodieren weg. Das kann den String um diese =-Zeichen kürzen. Die Struktur 3 Bytes → 4 Zeichen bleibt, also ist Base64URL kein platzsparenderes Binärformat.

Warum können winzige Eingaben um mehr als 33% wachsen?

1 Byte → 4 Zeichen ist 300% Längenzuwachs. 2 Bytes → 4 sind 100%. 3 Bytes → 4 sind etwa 33.3%. Je größer n, desto weniger zählt Padding, und der Mehrbedarf nähert sich etwa 33%. Base64 ist nicht in jedem Fall 33% größer.

Warum ist eine Base64-Data-URL noch größer?

Eine Data URL setzt ein Präfix wie data:image/png;base64, vor die Nutzlast. Bei einer winzigen Datei kann dieses Präfix den Prozentsatz beherrschen. Base64 kodieren und dekodieren kann Roh-Base64 oder eine Data URL ausgeben; Data-URL-Ausgabe nutzt das Standard-Alphabet.

Base64 vs. Binär: Was ist kleiner?

Roh-Binärdaten sind platzsparender für Transport und Speicherung. Base64 ist größer, aber texttauglich in JSON, E-Mail und anderen Nur-Text-Pfaden. Es ist Binär-zu-Text-Kodierung, keine Kompression.

Komprimiert Base64 Dateien?

Nein. Base64 ist kein Kompressionsformat. Der kodierte Text ist meist größer als die Original-Bytes. Wendest du später gzip oder Brotli auf diesen Text an, kann etwas Redundanz schrumpfen — das Ergebnis hängt von Daten und Kompressor ab. gzip entfernt den Base64-Mehrbedarf nicht vollständig.

Was passiert, wenn Base64 gzip bekommt?

HTTP-Kompression kann einige Wiederholmuster in Base64-Text reduzieren. JPEG, PNG oder ZIP komprimieren oft schlecht, selbst als Roh-Bytes, und Base64-dann-gzip bleibt fallabhängig. Es gibt keinen universellen Extra-Prozentsatz nach gzip.

Sollte man Dateien als Base64 speichern?

Base64 kann Binärdaten in ein JSON-Feld, ein kleines Inline-Asset, eine Nur-Text-API, Copy/Paste oder eine Data URL bringen. Bei großen Dateien wachsen Speicher, Arbeitsspeicher und Payload. Das heißt nicht „nie Base64 für Dateien“.

Warum ist Base64 in JSON-APIs üblich?

JSON hat keinen nativen Roh-Binärtyp, daher legen APIs Bytes oft in einen Base64-String. Für große Dateien können multipart/form-data, Object Storage oder ein direkter Binär-Upload besser passen. Keine Wahl ist immer die beste.

Warum wird Base64 in E-Mail genutzt?

MIME kann Base64 nutzen, damit ein binärer Anhang als texttaugliche Zeichen reist. Derselbe Größenzuwachs gilt weiter. Das ist eine Transportdarstellung, keine kleinere Datei.

Wann lohnt sich die Extra-Größe?

Die Extra-Größe kann lohnen, wenn Binärdaten in Text müssen, die Nutzlast klein ist, eine API Base64 verlangt oder du eine Data URL brauchst. Für große Medien bevorzuge Roh-Binärdaten, wenn das System das erlaubt.

Wann solltest du Base64 meiden?

Lass es bei großen Dateien, knapper Bandbreite, häufigen Transfers oder wenn schon ein Binärpfad existiert — situativ, nicht „Base64 ist schlechte Praxis“.

Base64-Längen mit Padding zum Nachprüfen

Original-Bytezahlen und Zeichenanzahlen von Standard-Base64 mit Padding:

Original-Bytes	Base64-Zeichen
1	4
2	4
3	4
10	16
100	136
1,000	1,336

Alle Zeilen folgen 4 × ceil(n / 3). Das sind Base64-Zeichenanzahlen.

Beispiel: Wie groß wird eine 1,000-Byte-Datei?

4 × ceil(1000 / 3). ceil(333.333…) = 334, und 4 × 334 = 1336. Also werden 1,000 Bytes zu 1,336 Base64-Zeichen. Als UTF-8/ASCII gespeichert ist jedes Zeichen typisch 1 Byte — behandle 1,336 nicht als genaue Bytezahl im Speicher.

Kann Base64 mehr Speicher brauchen, als die Dateigröße nahelegt?

Manche Laufzeiten speichern Strings mit mehr als 1 Byte je Zeichen, und Kodieren/Dekodieren kann Puffer und String gleichzeitig halten. Der Speicherbedarf ist nicht genau die Zeichenlänge.

Ein einfacher Größen-Entscheidungsleitfaden

Akzeptiert das System Roh-Binärdaten, bevorzuge sie der Größe wegen. Ist nur Text erlaubt, kann Base64 passen. Bei großer Nutzlast prüfe einen Binär-Upload-Pfad. Für URL-sicheren Text kommt Base64URL infrage — die 3-zu-4-Ausdehnung bleibt.

• Binärdaten senden müssen
• ↓
• Roh-Binärdaten erlaubt? Binär der Größe wegen bevorzugen
• Nur-Text-Feld? Base64 kann passen
• Große Nutzlast? Binär-Upload-Pfad prüfen
• URL-sicherer Text nötig? Base64URL erwägen
• ↓
• Bei großen Eingaben etwa 33% mehr Text erwarten

Base64 im Browser kodieren oder dekodieren

NEXNARA Base64 kodieren und dekodieren kodiert und dekodiert Text und kann eine Datei in Base64 oder eine Data URL verwandeln und Base64 wieder zur Datei machen.

Text nutzt UTF-8-Bytes, dann Base64 — nicht nur ASCII. Wähle Standard oder Base64URL. Dateiausgabe kann Roh-Base64 oder eine Data URL sein (Standard-Alphabet). Ungültige Eingabe wird abgelehnt. Nicht-UTF-8-Bytes brauchen den Weg zur Datei, nicht Text-Dekodierung.

Dateien über 10 MB können den Tab verlangsamen (Warnung). Dateien über 32 MB werden blockiert.

Kodieren und Dekodieren laufen in deinem Browser. Die Datei wird für dieses Tool nicht an einen NEXNARA-Server gesendet. Werbung und andere Site-Funktionen nutzen weiter das Netz.

Füge Text oder eine Datei in Base64 kodieren und dekodieren ein und vergleiche Original-Bytes mit der kodierten Länge.

FAQ

Warum vergrößert Base64 die Datei?

Es mappt 3 Bytes (24 Bits) auf 4 Zeichen (4 × 6 Bits). Als Text gespeichert ist das bei großen Eingaben etwa ein Drittel mehr.

Ist Base64 immer 33% größer?

Nein. Große Eingaben nähern sich etwa 33.3%. Winzige Eingaben können durch Padding stärker wachsen. Nimm 4 × ceil(n / 3).

Wie viel größer ist Base64 als Binärdaten?

Die Standard-Länge mit Padding ist 4 × ceil(n / 3) Zeichen. Ein Data-URL-Präfix fügt mehr hinzu.

Verringert Base64-Kompression die Dateigröße?

Base64 komprimiert nicht. gzip oder Brotli auf dem kodierten Text können etwas schrumpfen; sie tilgen den Mehrbedarf nicht in jedem Fall.

Nutzt Base64URL weniger Platz?

Es kann =-Padding weglassen, daher kann der String 0–2 Zeichen kürzer sein. Die 3-zu-4-Kodierstruktur bleibt gleich.

Soll ich Base64 für große Dateien nutzen?

Nur wenn du Text brauchst. Bei großen oder häufigen Transfers ist ein Binärpfad oft kleiner. Base64 ist für APIs nicht immer falsch.