Wie funktioniert Base64

Base64 wandelt Binärdaten in Text um, damit sie durch Kanäle reisen können, die nur Zeichen verarbeiten. RFC 4648 definiert den Mechanismus: Aus je 3 Bytes – 24 Bits – werden 4 Zeichen aus einem 64-Symbol-Alphabet, mit = als Padding, wenn sich die Bytes nicht glatt aufteilen. Die Daten werden um etwa ein Drittel größer, und es ist eine Kodierung, keine Verschlüsselung.

Nur lokal

E-Mail-Systeme der 1980er bewegten 7-Bit-Text und nichts sonst; HTTP-Header, JSON-Felder, URLs und Logdateien sind in der Praxis reine Textgebiete. Rohe Binärdaten – ein Bild, eine Signatur, ein kryptografischer Schlüssel – werden korrumpiert, sobald ein solcher Kanal auf sie trifft. Base64 ist die Standardbrücke: eine vollständig reversible Art, beliebige Bytes ausschließlich mit 64 sicheren druckbaren Zeichen auszudrücken.

Sie lesen den ganzen Tag Base64, ohne es zu bemerken: jedes JWT besteht aus drei Base64url-Segmenten, jede in CSS eingebettete data: URI, jeder MIME-E-Mail-Anhang. Das Verfahren ist in RFC 4648 spezifiziert – ein Dokument, das die früheren Base-64-Definitionen zusammenführte – und es ist klein genug, um es von Hand zu rechnen. Genau das tut dieser Leitfaden, eine 24-Bit-Gruppe nach der anderen.

Drei Dinge verwirren anfangs jeden: warum aus 3 Bytes 4 Zeichen werden, wozu die =-Zeichen dienen und warum es zwei Alphabete gibt. Jedes bekommt unten einen eigenen Abschnitt – zusammen mit den ehrlichen Grenzen: dem Größenmalus, dem Whitespace-Streit unter Dekodern und dem hartnäckigen Fehler, eine reversible Kodierung für Sicherheit zu halten.

Ansehen sagt hier mehr als Beschreiben – fügen Sie eine beliebige Zeichenkette in den Base64-Dekoder ein und sehen Sie, welche Bytes sie verbirgt; die Dekodierung läuft lokal, also bleiben Tokens und Schlüssel in Ihrem Tab.

Der bekannteste Base64-Konsument ist das Token-Format; der Leitfaden zur JWT-Struktur zeigt, wie die drei Segmente eines JWT auf dem unten definierten URL-sicheren Alphabet aufbauen.

Der Mechanismus: 3 Bytes hinein, 4 Zeichen hinaus

Nehmen Sie beliebige Binärdaten und schneiden Sie sie in Gruppen zu 3 Bytes – 24 Bits. Teilen Sie jede Gruppe in vier 6-Bit-Blöcke. Jeder Block ist eine Zahl von 0 bis 63, und das Alphabet aus RFC 4648 bildet diese Zahlen auf Zeichen ab: A–Z für 0–25, a–z für 26–51, 0–9 für 52–61, dann + und / für 62 und 63. Sechs Bits sind der optimale Kompromiss, denn 2⁶ = 64 ist exakt die Größe eines Alphabets, das jeder zeichenbasierte Kanal widerstandslos transportieren kann.

Das klassische Rechenbeispiel ist der eigene Testvektor des RFC, das Wort Man – drei Bytes, kein Padding nötig:

Byte für Byte

M   0x4D   01001101
a   0x61   01100001
n   0x6E   01101110

joined:    010011 010110 000101 101110
indexes:      19     22      5      46

Zeichen für Zeichen

19→T   22→W   5→F   46→u

"Man"  →  TWFu
"Ma"   →  TWE=
"M"    →  TQ==

Padding: Was die =-Zeichen bedeuten

6-Bit-Blöcke ergeben nur in ganzen Vierergruppen wieder Bytes. Ist die Eingabelänge kein Vielfaches von 3, bleibt die letzte Gruppe kurz: 2 übrige Bytes ergeben drei Zeichen plus ein =, 1 übriges Byte ergibt zwei Zeichen plus ==. Das Padding stellt die Länge wieder her, damit ein Dekoder die exakte Byteanzahl berechnen kann, ohne zu raten – und = ist das einzige Zeichen außerhalb des 64-Symbol-Alphabets, das in der Ausgabe auftauchen darf.

Padding ist Längen-Metadaten, keine Sicherheit und keine Kompression. RFC 4648 erlaubt Varianten ohne Padding, wenn beide Seiten zustimmen – das Base64url von JWTs verzichtet bekanntlich vollständig auf das =, weil die Punkte die Segmente trennen und die Länge jedes Segments dem Dekoder alles Nötige verrät.

Eingabe-Bytes	Ausgabe-Zeichen	Padding	Beispiel
3 (jedes Vielfache von 3)	4 je 3 Bytes	keine	"Man" → TWFu
2	3	ein =	"Ma" → TWE=
1	2	zwei ==	"M" → TQ==
12	16	keine	"Hello, world" → SGVsbG8sIHdvcmxk

Die zwei Alphabete: Standard und URL-sicher

Das Standardalphabet verwendet + und / – in E-Mails harmlos, in URLs gefährlich, wo + als Leerzeichen dekodiert wird und / als Pfadtrenner. RFC 4648 §5 definiert deshalb Base64url und ersetzt + durch - und / durch _: Zeichen, die in URLs keine Prozentkodierung brauchen und in Dateinamen oder Cookies nicht in Anführungszeichen gesetzt werden müssen. Im Übrigen sind beide Dialekte identisch – dieselben 6-Bit-Blöcke, dieselben Padding-Regeln.

Das ist die praktische Falle: Die Dialekte unterscheiden sich nur in zwei Zeichen, also scheitert ein mit dem falschen Alphabet eingefügter Token schon am zweiten Zeichen – oder schlimmer: Er dekodiert zu anderen Bytes, falls er zufällig + oder / enthält. Kooperative Dekoder akzeptieren beide Formen und verraten Ihnen, welche sie gesehen haben; strenge Dekoder lehnen gemischte Alphabete grundsätzlich ab, statt zu raten.

Werte	Standard	URL-sicher
0–25	A–Z	A–Z
26–51	a–z	a–z
52–61	0–9	0–9
62	+	-
63	/	_

Dieselben Bytes, zwei Dialekte

bytes:    0xFB 0xEF 0xBE

standard:  ++++
url-safe:  ----

Wo sich die Dialekte unterscheiden

in einer URL-Query kommt ++++ als vier Leerzeichen an
(Plus-als-Leerzeichen-Regel) – ---- kommt unverändert an.
Deshalb verwenden Tokens das URL-sichere Alphabet.

Größe: die Ein-Drittel-Steuer und ihr Kleingedrucktes

Vier Zeichen tragen drei Bytes, die kodierte Ausgabe ist also immer 4/3 der Eingabe – rund 33% mehr –, bevor überhaupt Transport-Overhead dazukommt. Konkrete Anker: 100 Bytes ergeben 136 Zeichen, 17 Bytes ergeben 24, und das Verhältnis bewegt sich nie, weil es Arithmetik ist und keine Stellschraube. Padding, Zeilenumbrüche und Umbrechen kommen obendrauf: MIME begrenzt Base64-Zeilen auf 76 Zeichen und verlangt dazwischen CRLF, was bei großen Nutzdaten ein wenig zusätzlich anfällt. Eine data: URI bettet diese ohnehin aufgeblähte Form in CSS oder HTML ein – deshalb wiegen inline eingebettete Bilder rund ein Drittel mehr als die Binärdateien, die sie ersetzen.

Nichts Reversibles verkleinert Daten, und Base64 bildet da keine Ausnahme – es ist eine Änderung der Schreibweise, keine Kompression. Wenn Größe zählt: erst komprimieren und dann die komprimierten Bytes kodieren – nie umgekehrt.

Whitespace, Zeilenumbrüche und Dekoder-Streitigkeiten

RFC 4648 ist streng: Dekoder müssen Zeichen außerhalb des Alphabets zurückweisen, und das Dokument selbst sagt nichts über vorgeschriebene Zeilenumbrüche. Das Base64 von MIME (RFC 2045) erwartet das Gegenteil – CRLF alle 76 Zeichen. Echte Implementierungen liegen zwischen diesen Polen: Viele entfernen Whitespace stillschweigend, manche bestehen darauf, manche weisen jeden Zeilenumbruch grundsätzlich zurück. Das ist der klassische Grund, warum eine Zeichenkette, die im einen Werkzeug „einwandfrei kodiert“, im anderen nicht dekodierbar ist.

Die ehrliche Interoperabilitätsregel: Erzeugen Sie standardmäßiges Base64 mit Padding und ohne Zeilenumbrüche, solange keine Spezifikation etwas anderes verlangt, und bauen Sie Dekoder, die den Whitespace anderer Werkzeuge tolerieren – aber trotzdem jedes Zeichen zurückweisen, das nicht Teil eines anerkannten Alphabets ist; denn genau diese Nachsicht ist der Anfang stiller Byte-Korruption.

Was Base64 nicht ist

Base64 hat keinen Schlüssel, keine Mischrunden, kein Geheimnis: Jeder kann es umkehren, und Dekoder liegen in der Standardbibliothek jeder Sprache bei. Kodierte Nutzdaten als geschützte Daten zu behandeln, taucht in Schwachstellenberichten immer wieder auf. Die verräterischen Merkmale sind öffentlich: SGVsbG8= schreibt Hello, JVBERi0x öffnet ein PDF, /9j/ beginnt ein JPEG, und eyJ steht am Anfang fast jedes JSON Web Token – diese ersten Zeichen sind schlicht Base64 für %PDF-, die JPEG-Magic-Bytes und eine öffnende JSON-Klammer.

Verwenden Sie Base64 für das, was es ist: eine in allen Containern sichere Schreibweise für Bytes. Vertraulichkeit gehört in echte Verschlüsselung – TLS bei der Übertragung, eine echte Chiffre für gespeicherte Daten –, und Base64 bleibt der letzte Schritt, der das Ergebnis druckbar macht, mehr nicht.

Verräterische Anfänge

SGVsbG8sIHdvcmxk
JVBERi0xLjQ=
/9j/
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Was daraus dekodiert wird

Hello, world
%PDF-1.4
(Bytes FF D8 FF – die magische Zahl eines JPEG)
{"alg":"HS256","typ":"JWT"}

Häufig gestellte Fragen

Kann ich Tokens und Schlüssel bedenkenlos in einen Base64-Dekoder einfügen?

Auf dieser Website: ja. Der Dekoder läuft in Ihrem Browser und überträgt Ihre Eingabe nie – es gibt keinen Upload-Endpunkt, über den etwas abfließen könnte. Das Netzwerk-Panel zeigt während des Dekodierens keine Anfragen, und die Content-Security-Policy der Website blockiert ausgehende Verbindungen. Relevant ist das, weil Base64-Tokens gültige Zugangsdaten sind und viele beliebige Web-Dekoder weit sorgloser mit ihnen umgehen.

Ist Base64 Verschlüsselung?

Nein – es ist eine Kodierung ohne Schlüssel und ohne Geheimhaltungseigenschaft. Jede Bibliothek und jeder aufmerksame Mensch kann sie sofort umkehren; ein kodiertes Passwort ist ein sichtbares Passwort. Verschlüsselung wandelt Daten so um, dass sie ohne Schlüssel unlesbar sind, während Base64 Bytes nur umschreibt, damit reine Textkanäle sie transportieren können. Beides löst verschiedene Probleme und tritt oft gemeinsam auf.

Warum endet die Base64-Ausgabe mit =-Zeichen?

Das = ist Padding, das die Länge wiederherstellt. Die Ausgabe kommt in 4-Zeichen-Gruppen, und war die Eingabe kein Vielfaches von 3 Bytes, wird die letzte Gruppe aufgefüllt – ein = für zwei übrige Bytes, zwei für eines, nie drei, denn eine vollständige Gruppe braucht keines. Die Zeichen tragen keine Daten; sie nennen dem Dekoder die exakte Byteanzahl.

Was ist der Unterschied zwischen Base64 und Base64url?

Zwei Zeichen. Base64url, definiert in RFC 4648 §5, ersetzt + durch - und / durch _, damit die Ausgabe ohne Escapen in URLs, Dateinamen und Cookies sicher ist. Alles andere – die 6-Bit-Gruppierung, die Buchstaben und Ziffern, die Padding-Regeln – ist identisch, und Formate wie JWTs verwenden die URL-sichere Variante ohne Padding.

Warum ist die Base64-Ausgabe größer als ihre Eingabe?

Jedes Ausgabezeichen trägt 6 Bits, ein Byte trägt 8, also brauchen 3 Bytes – 24 Bits – 4 Zeichen: feste 4/3, rund 33% Overhead, bevor Padding und Zeilenumbrüche dazukommen. Das ist der Preis der Druckbarkeit; keine reversible Kodierung entkommt ihm, weshalb roher Binärtransport gewinnt, wo der Kanal echte Bytes zulässt.

Kann ich Base64 von Hand dekodieren?

Ja – das Verfahren lädt dazu ein. Schreiben Sie die Bytes der Eingabe binär, gruppieren Sie jeden 24-Bit-Block in vier 6-Bit-Blöcke um und lesen Sie jeden Block in der Alphabet-Tabelle nach: A=0 bis Z=25, a=26 bis z=51, 0=52 bis 9=61, dann + und /. Das eigene Beispiel des RFC funktioniert auf dem Papier: Man ist 010011 010110 000101 101110, gelesen T, W, F, u – TWFu.

Wo kann ich die hier zitierten Standards nachlesen?

RFC 4648 — Die Datenkodierungen Base16, Base32 und Base64
RFC 2045 — MIME, Teil 1: Format von Internet-Nachrichtentexten

ToolsByUs-Team · Wie wir unsere Tools prüfen