Was ist Base64-Kodierung und warum heißt es 'Base64'?

Base64 ist ein Binär-zu-Text-Kodierungsschema, das Binärdaten mit 64 druckbaren ASCII-Zeichen darstellt: A–Z (26), a–z (26), 0–9 (10), plus '+' und '/' (2), insgesamt 64. Das '='-Zeichen wird als Padding verwendet. Es heißt Base64, weil es 64 mögliche Werte für jedes kodierte Zeichen gibt und jedes Zeichen genau 6 Bits der Originaldaten kodiert (2^6 = 64).

Verschlüsselt Base64-Kodierung meine Daten?

Nein. Base64 ist ein Kodierungsschema, kein Verschlüsselungsalgorithmus. Kodierung ist ohne Schlüssel umkehrbar — jeder, der eine Base64-Zeichenkette hat, kann sie sofort mit jedem Base64-Decoder dekodieren. Wenn Sie Daten vor unbefugtem Zugriff schützen müssen, müssen Sie Verschlüsselung (wie AES-256) verwenden — nicht Base64. Base64 ist nur nützlich, um Binärdaten für textbasierte Protokolle sicher zu machen — es bietet keinerlei Vertraulichkeit.

Wie viel größer ist die Base64-Ausgabe im Vergleich zu den Originaldaten?

Base64-Kodierung erhöht die Datengröße um ca. 33%. Jeweils 3 Bytes der Eingabe werden zu 4 Base64-Zeichen, plus Padding-Zeichen ('=') werden hinzugefügt, damit die Ausgabelänge ein Vielfaches von 4 ist. Zum Beispiel werden 3 Bytes zu 4 Zeichen, 6 Bytes zu 8 Zeichen, und 1 MB wird nach der Kodierung zu ca. 1,37 MB. Dieser Overhead ist der wichtigste Trade-off bei der Entscheidung, ob Base64 verwendet werden soll.

Was ist der Unterschied zwischen Standard-Base64 und URL-sicherem Base64?

Standard-Base64 verwendet '+' und '/' als 62. und 63. Zeichen. Diese Zeichen haben in URLs besondere Bedeutungen: '+' wird als Leerzeichen in Query-Strings dekodiert, und '/' ist ein Pfadtrennzeichen. URL-sicheres Base64 (auch Base64url genannt) ersetzt '+' durch '-' und '/' durch '_', sodass die kodierte Zeichenkette sicher in URLs und Dateinamen einbezogen werden kann. Padding-Zeichen ('=') werden in URL-sicher kodierten Kontexten oft ebenfalls weggelassen. JWT-Tokens verwenden zum Beispiel Base64url ohne Padding.

Sollte ich Base64 zum Speichern von Passwörtern verwenden?

Auf keinen Fall. Base64 ist trivial umkehrbar — jede Base64-Zeichenkette kann in Millisekunden auf ihren ursprünglichen Wert dekodiert werden. Das Speichern von Base64-kodierten Passwörtern ist gleichwertig mit dem Speichern im Klartext. Passwörter müssen mit einer geeigneten Passwort-Hash-Funktion wie bcrypt, scrypt oder Argon2 gehasht werden, die auf Rechenintensivität und Nichtumkehrbarkeit ausgelegt sind. Base64 hat keine Rolle bei der Passwortspeicherung.

Wann sollte ich Base64-Kodierung NICHT verwenden?

Vermeiden Sie Base64, wenn: (1) Sie Sicherheit benötigen — Base64 ist keine Verschlüsselung. (2) Sie große Dateien wie Bilder in HTML/CSS einbetten — der 33% Größen-Overhead und die Unfähigkeit, die Ressource separat zu cachen, beeinträchtigen die Leistung. (3) Sie große Binärdaten in einer Datenbank speichern — Binärdaten in einer dedizierten Binärspalte oder Objektspeicher wie S3 speichern, nicht als Base64-Zeichenketten. (4) Sie schnelle Verarbeitung benötigen — Base64-Kodierung und -Dekodierung fügt CPU-Overhead für große Payloads hinzu. Verwenden Sie Base64 nur, wenn Sie genuinen Bedarf haben, Binärdaten als ASCII-Text in einem Protokoll darzustellen, das kein rohes Binary verarbeiten kann.

Base64-Kodierung verstehen — Vollständiger Entwicklerleitfaden

10. Mai 2026 Toova

Base64-Kodierung erscheint in fast jedem Bereich der Webentwicklung — JWT-Tokens, Data-URIs, E-Mail-Anhänge, API-Payloads, kryptografische Signaturen und Konfigurationsdateien. Trotz ihrer Allgegenwart wird sie häufig missverstanden: Entwickler verwechseln sie manchmal mit Verschlüsselung oder verwenden sie in Situationen, in denen sie die Dinge verschlechtern. Dieser Leitfaden erklärt genau, wie Base64 funktioniert, wann es verwendet werden sollte, wann es vermieden werden sollte und wie es in JavaScript korrekt eingesetzt wird.

Was Base64-Kodierung ist (und was nicht)

Base64 ist ein Binär-zu-Text-Kodierungsschema. Seine einzige Aufgabe ist es, beliebige Binärdaten in eine Zeichenkette aus druckbaren ASCII-Zeichen umzuwandeln. Es komprimiert keine Daten, verschlüsselt keine Daten und validiert keine Daten. Es ist eine reine Darstellungstransformation — Bytes, die Null-Bytes, Steuerzeichen oder Werte enthalten könnten, die textbasierte Protokolle zum Absturz bringen würden, werden in einen sicheren Zeichensatz umgewandelt.

Der Name kommt von den 64 druckbaren Zeichen, die als Kodierungsalphabet verwendet werden: A–Z (26 Zeichen), a–z (26 Zeichen), 0–9 (10 Zeichen), plus + und / (2 Zeichen). Das Zeichen = wird als Padding verwendet. Da es 64 mögliche Werte pro Zeichenposition gibt und 2^6 = 64, kodiert jedes Base64-Zeichen genau 6 Bits der Originaldaten.

Wie Base64 funktioniert — "Hello" Schritt für Schritt

Der beste Weg, Base64 zu verstehen, ist, ein konkretes Beispiel zu verfolgen. Kodieren wir die Zeichenkette Hello.

Schritt 1: In Bytes umwandeln

Jedes Zeichen in Hello wird seinem ASCII-Code zugeordnet, der dann in Binärform ausgedrückt wird (8 Bits pro Byte):

H  e  l  l  o
72 65 6C 6C 6F   (ASCII / hex)
01001000 01100101 01101100 01101100 01101111   (binary)

Schritt 2: In 6-Bit-Gruppen einteilen

Alle Bits verketten: 0100100001100101011011000110110001101111 (40 Bits). Base64 verarbeitet 3 Bytes (24 Bits) gleichzeitig und ordnet sie 4 Base64-Zeichen zu (4 × 6 = 24 Bits). Die 40 Bits in 6-Bit-Gruppen einteilen und die letzte Gruppe mit Nullen auffüllen:

010010 000110 010101 101100 011011 000110 1111
18     6      21     44     27     6      (last group padded to 6 bits: 111100 = 60)

Schritt 3: Dem Base64-Alphabet zuordnen

Jeder 6-Bit-Wert wird einem Zeichen im Base64-Alphabet zugeordnet (A=0, B=1, ... Z=25, a=26, ... z=51, 0=52, ... 9=61, +=62, /=63). Da 5 Bytes kein Vielfaches von 3 ist, wird ein =-Padding-Zeichen hinzugefügt:

Index: 18  6   21  44  27  6   60
Char:  S   G   V   s   b   G   8
Result: SGVsbG8=   (= is padding)

Ergebnis

"Hello" → "SGVsbG8="

Das können Sie sofort mit dem Toova Base64-Kodierer/Dekodierer verifizieren — fügen Sie Hello ein, klicken Sie auf "Kodieren" und erhalten SGVsbG8=. Klicken Sie auf "Dekodieren", um es umzukehren.

Der 33%-Größen-Overhead

Base64-Kodierung erhöht die Datengröße immer um ca. 33%. Die Mathematik ist einfach: 3 Bytes der Eingabe (24 Bits) erzeugen 4 Base64-Zeichen (24 Bits kodiert in 4 × 6-Bit-Gruppen). Das ist ein 4/3-Verhältnis, also 33,3% Overhead. Mit Padding-Zeichen liegt der tatsächliche Overhead je nach Eingabelänge zwischen 33% und 36%.

Das hat erhebliche Auswirkungen auf die Leistung. Ein 1-MB-Bild, das als Base64-Data-URI in HTML eingebettet ist, wird zu ca. 1,37 MB. Eine API, die alle Binär-Payloads in Base64 kodiert, sendet 33% mehr Daten als nötig. Für kleine Werte wie kurze Tokens oder Prüfsummen ist der Overhead vernachlässigbar. Für große Dateien ist es ein echter Kostenfaktor.

Die URL-sichere Variante

Standard-Base64 verwendet + und / als die letzten zwei Alphabet-Zeichen. Beide sind in URLs problematisch:

+ wird als Leerzeichen in Query-Strings dekodiert
/ ist ein Pfadtrennzeichen in URLs

URL-sicheres Base64 (auch Base64url genannt, definiert in RFC 4648 Abschnitt 5) ersetzt + durch - und / durch _. Padding (=) wird in URL-sicheren Kontexten in der Regel weggelassen, da es ebenfalls von einigen URL-Parsern falsch interpretiert werden kann.

JWT-Tokens verwenden Base64url ohne Padding. Wenn Sie einen JWT-Header oder Payload manuell dekodieren, müssen Sie sowohl die Zeichensubstitution als auch das fehlende Padding verarbeiten. So geht das in JavaScript:

// URL-safe Base64 (replace + with - and / with _)
function toBase64Url(base64) {
  return base64.replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '');
}

function fromBase64Url(base64url) {
  const padded = base64url.padEnd(
    base64url.length + (4 - base64url.length % 4) % 4,
    '='
  );
  return atob(padded.replace(/-/g, '+').replace(/_/g, '/'));
}

Der Toova Base64-Kodierer/Dekodierer unterstützt Standard- und URL-sichere Varianten mit einem einzigen Umschalter.

Base64 in JavaScript

Browser: btoa() und atob()

Browser bieten zwei eingebaute Funktionen: btoa() (binary to ASCII, d. h. kodieren) und atob() (ASCII to binary, d. h. dekodieren). Trotz der verwirrenden Namensreihenfolge sind sie seit über einem Jahrzehnt in Browsern verfügbar.

// Browser — atob / btoa (strings only, ASCII-safe)
const encoded = btoa("Hello");
console.log(encoded); // "SGVsbG8="

const decoded = atob("SGVsbG8=");
console.log(decoded); // "Hello"

Wichtige Einschränkung: btoa() akzeptiert nur Zeichenketten mit Zeichen im Latin-1-Bereich (Code-Punkte 0–255). Wenn Sie eine Zeichenkette mit Unicode-Zeichen wie Emojis oder CJK-Zeichen übergeben, wirft es eine DOMException. Um beliebige Binärdaten zu kodieren, konvertieren Sie sie zuerst in ein Uint8Array:

// Browser — encoding arbitrary binary (Uint8Array)
const bytes = new Uint8Array([72, 101, 108, 108, 111]);
const encoded = btoa(String.fromCharCode(...bytes));
console.log(encoded); // "SGVsbG8="

Für das Kodieren beliebiger Zeichenketten, die Unicode-Zeichen enthalten können, ist der empfohlene moderne Ansatz, TextEncoder zu verwenden, um zuerst ein Uint8Array zu erhalten, und dann wie oben gezeigt zu kodieren.

Node.js: Buffer

Node.js bietet die Buffer-Klasse, die Binärdaten korrekt verarbeitet und mehrere Kodierungen einschließlich Base64 und Base64url unterstützt:

// Node.js — Buffer (handles binary safely)
const encoded = Buffer.from('Hello').toString('base64');
console.log(encoded); // "SGVsbG8="

const decoded = Buffer.from('SGVsbG8=', 'base64').toString('utf8');
console.log(decoded); // "Hello"

// URL-safe variant in Node.js
const urlSafe = Buffer.from('Hello').toString('base64url');
console.log(urlSafe); // "SGVsbG8" (no padding)

Die Kodierungsoption base64url (verfügbar seit Node.js 16) verarbeitet die Zeichensubstitution und Padding-Entfernung automatisch, was es viel einfacher macht als die Transformation manuell durchzuführen.

Für Browser-Umgebungen, die große Binärdateien verarbeiten müssen, kodiert die Methode FileReader.readAsDataURL die Datei als Base64-Data-URI, ohne alles auf einmal in den Speicher zu laden.

Wann Base64 verwenden

Binärdaten in textbasierten Protokollen einbetten

Der ursprüngliche Anwendungsfall für Base64 war die Kodierung binärer E-Mail-Anhänge in SMTP, einem Protokoll, das nur 7-Bit-ASCII-Text unterstützt. Das gleiche Prinzip gilt überall dort, wo Sie Binärdaten in ein Format einbeziehen müssen, das keine rohen Bytes verarbeiten kann: JSON-API-Payloads, XML-Dokumente, HTML-Attribute, CSS-Werte, HTTP-Header.

Data-URIs für kleine Assets

CSS und HTML ermöglichen es Ihnen, Bilder, Schriftarten und SVGs als Base64-Data-URIs einzubetten. Dadurch entfällt ein HTTP-Round-Trip für kleine Assets wie Icons und Flash-of-unstyled-content für kritische Above-the-Fold-Bilder wird eliminiert.

<!-- Inline SVG icon as Base64 data URI -->
<img src="data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0c..." alt="icon" />

<!-- Inline CSS background -->
.icon {
  background-image: url("data:image/png;base64,iVBORw0KGgo...");
}

Der Trade-off: Base64-Data-URIs können nicht separat von der HTML/CSS-Datei gecacht werden, die sie enthält. Wenn sich das Bild nie ändert, aber das umliegende HTML schon, lädt der Browser die Bilddaten bei jedem Seitenaufruf neu herunter. Verwenden Sie Data-URIs nur für kleine Assets (idealerweise unter 4 KB), wo das Eliminieren eines Round-Trips die Cache-Strafe aufwiegt.

Binärdaten für JSON oder URL-Parameter kodieren

JSON ist ein Textformat — es kann rohe Binär-Bytes nicht direkt darstellen. Wenn eine API Binärdaten übertragen muss (Bild-Thumbnails, kryptografische Signaturen, komprimierte Daten), ist Base64 der Standardweg, um sie in einem JSON-Payload einzubeziehen. Wenn Sie Binärdaten in einem URL-Query-Parameter übergeben müssen, stellt Base64url-Kodierung sicher, dass die Daten Percent-Encoding ohne Beschädigung überstehen.

JWT und andere Token-Formate

JWT-Tokens verwenden Base64url, um ihre Header- und Payload-Abschnitte zu kodieren. Dadurch wird der Token zu einer druckbaren, URL-sicheren Zeichenkette, die in HTTP-Headern, Cookies oder URL-Parametern übergeben werden kann. Die Kodierung dient nicht der Sicherheit (der Payload ist für jeden mit dem Token lesbar) — sie dient ausschließlich der sicheren Übertragung.

Wann Base64 NICHT verwenden

Sicherheit oder Vertraulichkeit

Base64 bietet null Sicherheit. Es ist in Millisekunden trivial umkehrbar. Verwenden Sie es nicht, um Passwörter, API-Schlüssel oder sensible Konfigurationswerte zu "verschleiern". Jeder Entwickler, der eine Base64-Zeichenkette sieht, wird sie sofort dekodieren. Wenn Sie Vertraulichkeit benötigen, verwenden Sie Verschlüsselung.

Passwortspeicherung

Das Speichern von Base64-kodierten Passwörtern ist gleichwertig mit dem Speichern im Klartext — die Kodierung ist sofort umkehrbar. Passwörter müssen mit einer geeigneten Passwort-Hash-Funktion wie bcrypt, Argon2 oder scrypt gehasht werden.

Große Binärdateien

Das Kodieren einer 10-MB-Datei als Base64 erzeugt eine 13,7-MB-Zeichenkette. Wenn Sie das in einer Datenbankspalte speichern, darin suchen oder über eine API übertragen, zahlen Sie jedes Mal den 33%-Overhead. Für große Binärdaten verwenden Sie dedizierten Binärspeicher: Datenbank-BLOB/BYTEA-Spalten, Objektspeicher wie S3 oder GCS, oder übertragen Sie das Binary direkt.

Situationen, in denen Sie Binary direkt verwenden können

Wenn Ihr Protokoll oder Format rohes Binary unterstützt — zum Beispiel ein WebSocket mit binärem Nachrichtentyp, ein multipart/form-data-HTTP-Upload oder ein binäres Dateiformat — verwenden Sie Binary direkt. Base64 ist nur notwendig, wenn das Transportmedium genuinen Bedarf hat, keine rohen Bytes zu verarbeiten.

Häufige Fallstricke

Kodierung mit Verschlüsselung verwechseln

Das ist der häufigste Fehler. Base64 ist sichtbar. Es ist kein Sicherheitsmechanismus. Code-Kommentare wie "Passwort wird Base64-kodiert zur Sicherheit gespeichert" zeigen ein ernsthaftes Missverständnis an, das im Code-Review aufgedeckt werden sollte.

btoa() mit Unicode-Zeichenketten verwenden

Das Aufrufen von btoa() auf einer Zeichenkette, die Zeichen mit Code-Punkten über 255 enthält, wirft eine DOMException: Failed to execute 'btoa': The string to be encoded contains characters outside of the Latin1 range. Immer über TextEncoder in Uint8Array konvertieren, bevor Zeichenketten kodiert werden, die Unicode-Zeichen enthalten können.

Padding beim Dekodieren vergessen

Base64-Zeichenketten müssen Längen haben, die ein Vielfaches von 4 sind. Wenn eine Base64-Zeichenkette ohne Padding generiert wurde (üblich bei URL-sicherer Kodierung), müssen Sie die richtige Anzahl von =-Zeichen vor dem Dekodieren zurückfügen. Eine Base64-Zeichenkette mit Länge n benötigt (4 - n % 4) % 4 Padding-Zeichen. Das Vergessen verursacht Decode-Fehler, die schwer zu diagnostizieren sein können.

Doppelkodierung

Eine Base64-Zeichenkette ist selbst gültiges ASCII, sodass btoa(btoa(data)) ohne Fehler funktioniert, aber doppelt kodierte Ausgabe erzeugt. Wenn Base64-Werte durch mehrere Serialisierungsschichten übergeben werden (JSON in JSON, zum Beispiel), ist es leicht, dieselben Daten zweimal zu kodieren. Immer genau so oft dekodieren, wie kodiert wurde.

Kurzreferenz: Base64 in der Praxis

Zum Kodieren und Dekodieren im Browser ohne Code zu schreiben läuft der Toova Base64-Kodierer/Dekodierer vollständig in Ihrem Browser — kein Server-Round-Trip. Er unterstützt Standard- und URL-sichere Varianten, Datei-Upload zum Kodieren von Binärdateien und sowohl Text- als auch Hex-Ausgabe für dekodierte Daten.

Wenn Sie mit kodierten Inhalten in URLs arbeiten, verarbeitet der URL-Kodierer/Dekodierer Percent-Encoding separat von Base64. Für HTML-Entities verarbeitet der HTML-Entities-Konverter Zeichenescaping in HTML-Kontexten. Das sind verschiedene Kodierungsschemas — jedes hat einen spezifischen Anwendungsfall.

Die kanonische Referenz für Base64 ist RFC 4648, das Standard-Base64 (Abschnitt 4), Base64url (Abschnitt 5) und Base32 (Abschnitte 6–7) definiert. Für die Browser-APIs btoa() und atob() deckt die MDN-Dokumentation für btoa() Browser-Kompatibilität und die Unicode-Einschränkung im Detail ab.

Zusammenfassung

Base64-Kodierung wandelt Binärdaten mit einem 64-Zeichen-Alphabet in druckbare ASCII um. Es erhöht die Datengröße um 33%, ist vollständig umkehrbar und bietet keine Sicherheit. Verwenden Sie es, wenn Sie Binärdaten in einem textbasierten Format einbetten müssen — JSON-Payloads, HTML-Data-URIs, JWT-Tokens, E-Mail-Anhänge, URL-Parameter. Vermeiden Sie es, wenn Sie Sicherheit benötigen, wenn das Transport-Medium Binary direkt unterstützt oder wenn der 33%-Overhead im großen Maßstab wichtig ist.

Das Verstehen, was Base64 ist — und was es nicht ist — verhindert die häufigsten Fehler: es für Sicherheit zu verwenden, es unnötig auf große Dateien anzuwenden und es mit anderen Kodierungsschemas wie URL-Kodierung oder HTML-Entities zu verwechseln. Jedes Kodierungsschema löst ein spezifisches Problem. Base64 löst genau eines: Binärdaten für rein textbasierte Kanäle sicher zu machen.

Bereit zum Kodieren oder Dekodieren? Probieren Sie den Toova Base64-Kodierer/Dekodierer — Text einfügen oder eine Datei ablegen, Standard oder URL-sicher umschalten und das Ergebnis kopieren. Kein Konto, kein Server, keine Grenzen.