Base64-Konverter

Wann nutzt du base64 encode und wann base64 decode?

Beim base64 encode wandelst du normalen Text oder Bytes in eine Base64-Zeichenfolge um. Das brauchst du zum Beispiel, wenn Daten in einem Format transportiert werden sollen, das nur gut mit sichtbaren Textzeichen umgehen kann. Aus „Hallo Welt!“ wird dann „SGFsbG8gV2VsdCE=“. Die Rechnung zeigt dazu „11 Bytes“, „16 Zeichen“ und einen Größenzuwachs von „45,5 %“.

Beim base64 decode gehst du den umgekehrten Weg: Du hast bereits eine Base64-Zeichenfolge und möchtest wieder lesbaren Text oder die ursprünglichen Bytes sehen. „SGVsbG8gd2VsdA==“ wird zum Beispiel zu „Hello welt“. Angezeigt werden dazu „10 Bytes“, „16 Zeichen“ und „60 %“ Größenzuwachs bezogen auf die ursprünglichen Daten.

Im Rechner wählst du die gewünschte Richtung, fügst die Eingabe ein und stellst bei Bedarf den Zeichensatz oder den MIME-Zeilenumbruch ein.

Merke dir die einfache Unterscheidung: Encode heißt Text zu Base64, Decode heißt Base64 zurück zu Text. Wenn dein Ergebnis nach dem Dekodieren unlesbar wirkt, ist nicht automatisch die Base64-Zeichenfolge falsch. Häufig passt nur der Zeichensatz nicht oder du hast statt normalem Base64 eine base64url-Variante vor dir.

Wie funktioniert die Rechnung bei base64 decode und encode?

Base64 verarbeitet nicht direkt Buchstaben, sondern Bytes. Die Formel lautet: Länge Base64 = 4 × ⌈Bytes ÷ 3⌉ Zeichen. In Worten: Die Daten werden in Blöcke aus je 3 Bytes zerlegt. Jeder Block wird als 24 Bit betrachtet und danach in 4 Gruppen mit je 6 Bit aufgeteilt. Jede dieser Gruppen zeigt auf ein Zeichen im Base64-Alphabet.

Das Beispiel „Hallo“ zeigt den Ablauf kompakt:

• Eingabetext: „Hallo“
• Datenmenge: „5 Bytes“
• Bytes hexadezimal: „48 61 6C 6C 6F“
• Base64-Ergebnis: „SGFsbG8=“
• Base64-Länge: „8 Zeichen“
• Größenzuwachs: „60 %“

Die Rechnung dahinter: „5 Bytes“ ergeben „2 Blöcke à 3 Bytes“. Weil der letzte Block nicht vollständig gefüllt ist, erscheint am Ende „1 × „=“ als Füllung“. Dieses Zeichen gehört also nicht zum ursprünglichen Text, sondern macht die Blockstruktur vollständig.

Beim Dekodieren läuft derselbe Mechanismus rückwärts. Die Base64-Zeichen werden wieder in ihre Werte übersetzt, daraus entstehen Bitgruppen, daraus wieder Bytes. Aus den Bytes wird anschließend Text im gewählten Zeichensatz, meist UTF-8. Deshalb kann dieselbe Bytefolge anders aussehen, wenn du den falschen Zeichensatz auswählst.

Warum wird Base64 größer als der Ursprungstext?

Base64 ist eine Darstellung, keine Komprimierung. Es verpackt Bytes in ein Textalphabet. Dadurch entstehen meist mehr Zeichen als im Original. Bei großen Daten liegt der Zuwachs oft nahe bei „33,3 %“, bei kleinen Eingaben kann er deutlich höher ausfallen, weil die Blöcke aufgefüllt werden müssen.

Ein paar Größen aus typischen Rechnungen zeigen den Unterschied:

Originalgröße	Base64-Zeichen	Zuwachs
1 Byte	4	300 %
2 Bytes	4	100 %
3 Bytes	4	33,3 %
10 Bytes	16	60 %
100 Bytes	136	36 %
1 kB	1.336	33,6 %
1 MB	1.333.336	33,3 %

Der Effekt fällt bei kurzen Texten besonders auf. „1234567890“ hat „10 Bytes“, wird aber zu „MTIzNDU2Nzg5MA==“ mit „16 Zeichen“. Das ergibt „60 %“ Zuwachs. Bei „benutzer:geheim“ sind es „15 Bytes“ und „20 Zeichen“, also „33,3 %“. Der Unterschied kommt daher, ob die Eingabe genau in die Blöcke passt oder ob Padding nötig ist.

Wenn du Base64 in E-Mails oder älteren MIME-Kontexten verwendest, kann zusätzlich ein Zeilenumbruch nach „76 Zeichen“ gesetzt werden. Das ändert die Lesbarkeit und das Transportformat, aber nicht den eigentlichen Inhalt der dekodierten Bytes.

Base64url, JWT und normale Base64-Zeichenfolgen unterscheiden

Normales Base64 und base64url sehen sehr ähnlich aus, sind aber nicht immer austauschbar. Standard-Base64 nach RFC 4648 Abschnitt 4 verwendet das Alphabet mit „A-Z, a-z, 0-9, + und /“. base64url nach RFC 4648 Abschnitt 5 ist für URL- und Token-Kontexte gedacht und wird häufig ohne Padding ausgegeben.

Ein einfaches Beispiel: Der Text „JWT Test 123“ wird als base64url zu „SldUIFRlc3QgMTIz“. Die Rechnung zeigt „12 Bytes“, „16 Zeichen“ und „33,3 %“ Zuwachs. Bei JWT-Teilen ist base64url besonders häufig. Ein JWT-Header aus dem Beispiel „eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9“ wird zu „{„alg“:„HS256“,„typ“:„JWT“}“ und hat „27 Bytes“ sowie „36 Zeichen“.

Wenn ein JWT-Teil oder ein URL-Parameter im normalen Decoder scheitert, prüfe zuerst die Variante. Besonders auffällig sind fehlende „=“-Zeichen am Ende oder Zeichen, die im URL-Kontext vorkommen. Der base64url-Modus ist dann meist die passende Wahl.

Noch ein Praxisfall: „ZXlKcGJtTnZaR1Z5SWpwYkltVjRjR2x5WlQwPQ“ wird im base64url-Modus zu „eyJpbmNvZGVyIjpbImV4cGlyZT0=“. Die Rechnung zeigt „28 Bytes“, „38 Zeichen“ und „35,7 %“ Zuwachs. Dass im dekodierten Text wieder ein „=“ auftaucht, ist kein Widerspruch. Es ist dann Teil des dekodierten Inhalts.

Typische Fehler beim Base64 dekodieren vermeiden

Der häufigste Irrtum: Base64 wird mit Verschlüsselung verwechselt. Base64 schützt nichts. Wenn du einen API-Schlüssel, ein Passwort oder einen Token in Base64 siehst, ist der Inhalt nur anders dargestellt. Wer die Zeichenfolge hat, kann sie ohne Schlüssel zurückwandeln. Für Geheimhaltung brauchst du ein anderes Verfahren.

Achte außerdem auf diese Punkte:

• Falsche Richtung: Wenn du lesbaren Text eingibst, brauchst du Encode. Wenn du eine Base64-Zeichenfolge eingibst, brauchst du Decode.
• Falsche Variante: JWTs und URL-Parameter nutzen oft base64url, nicht normales Base64.
• Falscher Zeichensatz: UTF-8 ist der übliche Standard. ISO-8859-1 passt eher zu alten Latin1-Daten.
• Padding falsch bewertet: „=“ am Ende ist häufig nur Füllung und kein Inhalt.
• Zeilenumbrüche falsch kopiert: MIME kann Zeilenumbrüche enthalten. Beim reinen Vergleich von Zeichenfolgen können sie stören.

Umlaute zeigen gut, warum der Zeichensatz zählt. „Füße, Öl und Grüße“ wird mit UTF-8 zu „RsO8w59lLCDDlmwgdW5kIEdyw7zDn2U=“. Die Rechnung meldet „23 Bytes“, obwohl der sichtbare Text weniger Zeichen enthält. Der Grund: Zeichen wie „ü“, „ß“ oder „Ö“ benötigen in UTF-8 andere Bytefolgen als einfache ASCII-Buchstaben.

Wenn du beim Dekodieren nur kryptische Zeichen erhältst, prüfe daher zuerst: Ist es wirklich Text? Ist die Variante korrekt? Passt UTF-8 oder ISO-8859-1? Erst danach lohnt sich die Suche nach einer beschädigten Eingabe.