Base64-Kodierer & -Dekodierer

Kodieren Sie Text zu Base64 oder dekodieren Sie Base64 zurück in lesbaren Text. Unterstützt vier Formatmodi: Zeichenkette, JSON, XML und YAML. JSON, XML und YAML werden beim Dekodieren automatisch formatiert. Außerdem: Bild-Base64-Konverter | Datei zu Base64 | Hex ↔ Base64.
Die gesamte Verarbeitung findet lokal in Ihrem Browser statt — Ihre Daten werden nie auf einen Server hochgeladen.
Format: Richtung:
Alphabet: Zeilenumbruch:
Eingabe (Zeichenkette)
Ausgabe (Base64)
What is Base64? Base64 is a binary-to-text encoding scheme that represents data using 64 ASCII characters (A-Z, a-z, 0-9, +, /). It is commonly used to transmit binary data over text-based protocols like HTTP, JSON, or XML.
String mode: Direct encode/decode of any text.
JSON/XML/YAML modes: When decoding, the result is validated, parsed, and pretty-printed for readability. When encoding, the input is validated before being Base64-encoded.
URL-safe: Replaces + with - and / with _, and strips trailing = padding — safe to use in URLs and filenames without percent-encoding.
Was ist Base64?

Base64 schreibt Bytes mit vierundsechzig lesbaren Zeichen um, damit die Daten einen für Text gebauten Kanal überstehen: den Textkörper einer E-Mail, eine JSON-Zeichenkette, ein XML-Attribut, eine URL. Jeweils drei Bytes werden zu vier Zeichen, daher kommt der Name — das Alphabet hat vierundsechzig Symbole, und jedes trägt genau sechs Bit.

Es ist eine Transportkodierung, keine Sicherheitsmaßnahme und kein Kompressionsschritt. Die Ausgabe ist etwa ein Drittel größer als die Eingabe, und wer die Zeichenkette hat, kann sie sofort zurückrechnen. Wenn Sie wissen wollen, ob Daten verändert wurden, brauchen Sie einen Hash (Hash-Generator); wenn sie geheim bleiben sollen, brauchen Sie Verschlüsselung. Base64 leistet keines von beiden.

Die eine Zahl, die man sich merken sollte: Drei Eingabebytes werden zu vier Ausgabezeichen. Alles Weitere auf dieser Seite folgt daraus. Vier Zeichen tragen vierundzwanzig Bit, und vierundzwanzig Bit sind genau drei Byte, daher gehen nie Daten verloren oder entstehen neue — außer ganz am Ende, wo die Eingabe die letzte Dreiergruppe möglicherweise nicht füllt.
Die fünf Alphabete, die diese Seite verwenden kann

Die ersten beiden Zeilen sind Normen, die letzten drei sind Konventionen, die sich rund um Unix entwickelt haben. Alle fünf tragen pro Zeichen dieselben sechs Bit und unterscheiden sich nur darin, welche vierundsechzig Zeichen die Aufgabe übernehmen; dieselben Bytes werden daher zu fünf verschiedenen Zeichenketten. In einer Zeichenkette steht nirgends, welches Alphabet sie erzeugt hat; deshalb ist die Alphabetauswahl standardmäßig auf Standard eingestellt und das Kontrollkästchen URL-sicher ist eine Abkürzung für die zweite Zeile.

So wählt die Seite einen Kandidaten: Die Auswahl ist für beide Richtungen die Voreinstellung. Beim Dekodieren liest das Feld rechts auch die Zeichenkette selbst — - und _ kommen nur aus dem URL-sicheren Alphabet vor, + oder / nur aus dem Standardalphabet, und ein / oder . nahe dem Anfang weist auf die beiden Unix-Alphabete hin. Jedes Alphabet, das die aktuelle Eingabe lesen kann, ist dort aufgeführt, mit dem Grund, warum es ein Kandidat ist oder nicht.
Zeilenumbruch: 76 und 64 Zeichen

MIME verlangte Base64, das in eine E-Mail passt, ohne dass eine Zeile unvernünftig lang wird, und einigte sich auf 76 Zeichen pro Zeile, getrennt durch CRLF. PEM-Dateien, die Zertifikate und Schlüssel umschließen, verwenden 64. Die Zeilenumbrüche gehören nicht zu den Daten: Ein Dekodierer entfernt sie und fügt die Zeilen zusammen, bevor er irgendetwas anderes tut; eine umbrochene und eine nicht umbrochene Zeichenkette ergeben daher exakt dieselben Bytes. Jede Zeile außer der letzten enthält eine ganze Zahl von Vierergruppen, und genau das macht das Zusammenfügen sicher.

Diese Seite lässt die Ausgabe in einer Zeile, außer Sie wählen eine Breite, und der Dekodierer akzeptiert Eingaben mit oder ohne Zeilenumbrüche. Die Umbrüche dieser Seite sind einfache Zeilenvorschübe, wie sie ein Textfeld aufnehmen kann; MIME-Mailtexte verwenden traditionell vor jedem Zeilenvorschub einen Wagenrücklauf, und jeder gebräuchliche Dekodierer akzeptiert beides.

Auffüllung, und warum sie wegfallen kann

Ist die Eingabe kein Vielfaches von drei Byte, ist die letzte Vierergruppe unvollständig, und ein oder zwei =-Zeichen füllen sie auf. Sie tragen überhaupt keine Daten: Sie sagen nur, wie viele der vier Zeichen echt sind. Ein Dekodierer kann das stattdessen aus der Länge ableiten, und deshalb lässt URL-sicheres Base64 die Auffüllung traditionell weg — ein = ist in einer URL oder einem Dateinamen unbequem, und manche Systeme kodieren es prozentual.

Das Kontrollkästchen in der Optionszeile behält die Auffüllung bei, wenn das URL-sichere Alphabet gewählt ist. Sonst ändert sich nichts; die datentragenden Zeichen sind in beiden Fällen gleich.

Verbreitete Missverständnisse
  • „Base64 verbirgt die Daten.“ Nein. Es ist eine Ersetzung ohne Schlüssel, und der ganze Sinn ist, dass jeder Leser sie rückgängig machen kann. Ein Passwort oder ein Token in Base64 zu schreiben ändert nichts daran, wer es lesen kann.
  • „Base64 komprimiert.“ Das Gegenteil: Jeweils drei Eingabebytes werden zu vier Ausgabezeichen, der Text ist also ein Drittel größer als die Daten, die er trägt.
  • „Die Zeilenumbrüche gehören zum Wert.“ Sie sind nur Darstellung. Hinzufügen oder Entfernen ändert nie die Bytes, die wieder herauskommen.
  • „URL-sicher ist eine andere Kodierung.“ Es ist dieselbe Kodierung mit zwei vertauschten Zeichen: + wird zu - und / zu _, damit die Zeichenkette in einem URL-Pfad oder einem Abfragewert ohne Maskierung stehen kann.
  • „Eine Zeichenkette, die sich dekodieren lässt, muss gültiges Base64 sein.“ Jede Zeichenkette aus Alphabetzeichen ist gültiges Base64, weil jede Kombination von Sechs-Bit-Werten eine gültige Byte-Folge ergibt. Falsch wird eine Zeichenkette erst im nächsten Schritt, wenn diese Bytes gegen das Format geprüft werden, das sie sein sollten.
  • „Die Auffüllung verrät, welches Alphabet verwendet wurde.“ Nein, und meist verraten es auch die Zeichen nicht: Das Standard- und das URL-sichere Alphabet stimmen bei zweiundsechzig ihrer vierundsechzig Symbole überein, daher liest sich eine kurze Zeichenkette oft in beiden gleich.
Häufige Fragen

Warum endet eine Base64-Zeichenkette manchmal mit einem = und manchmal mit zwei? Eines bedeutet, dass die letzte Gruppe drei echte Zeichen trägt, also zwei Eingabebytes; zwei bedeuten, dass sie zwei trägt, also ein Eingabebyte. Kein = bedeutet, dass die Eingabelänge ein Vielfaches von drei war.

Kann Base64 beliebige Binärdateien darstellen? Ja, und das ist sein Hauptzweck. Diese Seite behandelt die Eingabe als UTF-8-Text; das eigene Werkzeug Datei zu Base64 liest Rohbytes, wenn Sie etwas kodieren wollen, das kein Text ist.

Welches Alphabet sollte ich in einer API verwenden? Das, was die empfangende Seite dokumentiert. Steht dort URL-sicher, verwenden Sie das; steht nichts dazu und der Wert wandert in einer URL, ist URL-sicher ohne Auffüllung die sichere Wahl.

Ist die Ausgabe groß-/kleinschreibungsabhängig? Vollständig. a und A sind verschiedene Werte, deshalb übersteht Base64 einen verschriebenen Buchstaben viel schlechter als Base32 oder Crockford Base32.