Text und Base64 in beide Richtungen
Text in Base64 codieren oder eine Base64-Zeichenkette zurück in Text wandeln
Ihre Daten bleiben bei Ihnen. Die Umwandlung läuft im Browser; nichts wird an einen Server gesendet.
Hat dieses Werkzeug geholfen?
Danke, Ihre Rückmeldung ist angekommen.
So funktioniert es
Fügen Sie Ihren Text in das linke Feld ein und wählen Sie die Richtung; das Ergebnis erscheint beim Tippen im rechten Feld. Das Codieren läuft in zwei Schritten ab: Der Text wird in UTF-8-Bytes umgewandelt, und erst auf diese Bytes wird das 64 Zeichen große Base64-Alphabet angewendet — deshalb überstehen ä, ö, ü, ß und Emoji den Weg unbeschädigt. Beim Decodieren ist das Werkzeug bewusst nachsichtig damit, wie die Zeichenkette bei Ihnen ankommt: Leerzeichen und Zeilenumbrüche werden übergangen, ein vorangestelltes data:text/plain;base64, wird entfernt, und die URL-sicheren Zeichen - und _ werden auf + und / zurückgeführt. Enthält die Zeichenkette ein Zeichen, das nicht zum Alphabet gehört, nennt die Meldung dieses Zeichen und seine Position; sitzt die Füllung an der falschen Stelle oder passt die Länge nicht, wird das getrennt gemeldet. Ergeben die decodierten Bytes keinen gültigen UTF-8-Text, erfahren Sie auch das, denn dann halten Sie keine Zeichenkette, sondern eine Datei in der Hand. Die Ergebniszeile zeigt, wie viele Zeichen zu wie vielen Bytes und wie vielen Base64-Zeichen geworden sind.
Dieses Werkzeug ist auch als base64 codieren, base64 dekodieren, text in base64 umwandeln, base64 in text umwandeln, base64 konverter bekannt.
Was ist Base64?
Base64 schreibt Daten in einem Alphabet aus 64 Zeichen: A-Z, a-z, 0-9 sowie + und /. Es liest drei Bytes auf einmal, teilt diese 24 Bit in vier Gruppen zu je 6 Bit und schreibt pro Gruppe ein Zeichen; geht die Eingabe nicht glatt auf, füllt = die letzte Gruppe auf. Weil das Ergebnis druckbarer Text ist, übersteht es Header, Protokollzeilen, Konfigurationsdateien und JSON-Felder, die Rohdaten zerstören würden. Der Preis ist Größe: etwa ein Drittel mehr als das Original. Entscheidend ist, dass das Alphabet auf BYTES angewendet wird, nicht auf Zeichen — der Text muss also zuerst UTF-8 werden.
Was ist UTF-8?
UTF-8 legt jedes Zeichen in einem bis vier Bytes ab und ist die Standardcodierung des Webs. Buchstaben ohne diakritische Zeichen belegen ein Byte; ä, ö, ü und ß belegen zwei, ebenso griechische und kyrillische Buchstaben; die meisten CJK-Zeichen belegen drei, Emoji vier. Deshalb sind die Zeichenzahl einer Zeichenkette und ihre Byte-Zahl zwei verschiedene Werte — ein deutscher Satz mit 30 Zeichen kann 34 Bytes lang sein. Das ist keine Theorie: Base64-Größe, Feldlängen in Datenbanken und Dateigrößen zählen alle in Bytes, und die Ergebniszeile nennt hier beide Werte.
Ist Base64 eine Verschlüsselung?
Nein. Base64 ist eine Codierung, keine Verschlüsselung, und der Unterschied ist der Schlüssel. Verschlüsselung braucht ein Geheimnis, um rückgängig gemacht zu werden; eine Codierung ist eine veröffentlichte Regel, die jeder mit einem Klick umkehren kann — auch auf dieser Seite. Base64-Ausgaben sehen unlesbar aus, und genau deshalb werden sie so oft für eine Sicherheitsmaßnahme gehalten. Einen API-Schlüssel, ein Passwort oder personenbezogene Daten durch Base64 zu schicken und sie damit für verborgen zu halten, ist ein verbreiteter und gefährlicher Irrtum: Der Wert steht weiterhin offen da, einen Schritt von jedem entfernt, der ihn kopiert. Nutzen Sie Base64, um Daten durch einen reinen Textkanal zu bringen, und echte Verschlüsselung, wenn die Daten geheim bleiben müssen.
Warum btoa an Umlauten scheitert
Die eingebaute Funktion btoa des Browsers nimmt nur Einzelbyte-Werte von 0 bis 255 an. Ein ä oder ß belegt in UTF-8 zwei Bytes, deshalb wirft btoa entweder einen InvalidCharacterError oder codiert — wenn der Text vorher in Latin-1 gepresst wurde — die falschen Bytes. Auf der Gegenseite steht dann Buchstabensalat wie ä statt ä.
Dieses Werkzeug überspringt den Zwischenschritt nicht: erst UTF-8-Bytes, dann das Alphabet auf diese Bytes. Beim Decodieren läuft derselbe Weg rückwärts, deshalb erhalten Sie nach Codieren und erneutem Decodieren Zeichen für Zeichen das Original zurück, Emoji eingeschlossen.
Wo Ihnen Base64 tatsächlich begegnet
Base64 entstand für Kanäle, die Text befördern können, Rohdaten aber nicht. Heute wird es genauso oft eingesetzt, um einem Trennzeichen-, Anführungszeichen- oder Zeichensatzproblem an einer Stelle auszuweichen, die nur eine einzige Zeile Text akzeptiert.
- Benutzername und Passwort im HTTP-Header Basic Authorization
- Die drei Abschnitte eines JWT, geschrieben im URL-sicheren Alphabet
- E-Mail-Anhänge und MIME-Rümpfe während der Übertragung
- Zertifikate und private Schlüssel, einzeilig in eine Konfigurationsdatei gesetzt
- Lange Werte in einem JSON-Feld, um Maskierungsprobleme zu vermeiden
Beim Decodieren gehen zwei verschiedene Dinge schief
Der erste Fall ist ein Alphabetfehler: In der Zeichenkette steht ein Zeichen, das Base64 nicht verwendet, die Füllzeichen = stehen nicht am Ende, oder die Länge kann nicht stimmen. Fast immer ist die Kopie unvollständig — prüfen Sie, ob die abschließenden Gleichheitszeichen mitgekommen sind.
Der zweite Fall ist ein Textfehler: Die Zeichenkette ist gültiges Base64, die Bytes entstehen sauber, ergeben aber keinen gültigen UTF-8-Text. Dann sind die Daten ein Bild, ein PDF oder ein Archiv, und kein Textwerkzeug kann sie anzeigen. Decodieren Sie solche Daten in eine Datei statt in eine Zeichenkette.
Häufige Fragen
Wie decodiere ich eine Base64-Zeichenkette?
Fügen Sie die Zeichenkette links ein und stellen Sie die Richtung auf Decodieren. Leerzeichen und Zeilenumbrüche werden übergangen und ein data:-Präfix wird entfernt, Sie können also einfügen, was Sie vorgefunden haben.
Werden URL-sichere Zeichenketten (base64url) unterstützt?
Beim Decodieren ja: - und _ werden auf + und / zurückgeführt, fehlende Füllzeichen werden verkraftet. Codiert wird immer im Standardalphabet, also mit + und / statt mit - und _.
Was bedeuten die Gleichheitszeichen am Ende?
Base64 liest drei Bytes und schreibt vier Zeichen. Bleibt am Schluss eine kürzere Gruppe übrig, füllen ein oder zwei = die Ausgabe auf ein Vielfaches von vier auf. Sie gehören zur Zeichenkette; fehlen sie, kann das Decodieren scheitern.
Warum ist die codierte Zeichenkette länger als mein Text?
Aus drei Bytes werden immer vier Zeichen, die Ausgabe ist also rund ein Drittel größer als die Eingabe, zuzüglich Füllung. Das ist der Preis dafür, Binärdaten durch einen reinen Textkanal zu schicken.
Wird mein Text irgendwohin gesendet?
Nein. Codieren und Decodieren laufen in Ihrem Browser. Ein Token, ein Schlüssel oder eine Konfigurationsdatei verlässt diese Seite nicht, und das Werkzeug arbeitet auch ohne Netzverbindung weiter.