Base64 verwandelt beliebige Bytes in eine Zeichenkette aus 64 sicheren Zeichen, damit Daten, die nie als Text gedacht waren, durch Kanäle passen, die nur Text akzeptieren. Entworfen wurde es in den Neunzigern für E-Mail-Anhänge, und es ist immer noch überall: Data-URIs, JWTs, HTTP-Basic-Auth-Header, JSON-Payloads mit binären Blobs.
Was die Kodierung tatsächlich macht
Der Encoder liest die Eingabe in Dreierschritten. Drei Bytes sind 24 Bit, die er in vier Gruppen zu je sechs Bit neu zerteilt. Sechs Bit fassen 64 Werte, und jeder dieser Werte entspricht einem Zeichen aus dem Alphabet A–Z, a–z, 0–9 sowie "+" und "/". Das ist der ganze Trick.
Ist die Eingabelänge kein Vielfaches von drei, bleibt die letzte Gruppe unvollständig und der Encoder füllt die Ausgabe mit einem oder zwei "=" auf, damit das Ergebnis immer glatt durch vier teilbar ist. Deshalb enden manche Zeichenketten mit Gleichheitszeichen und andere nicht: Es verrät die ursprüngliche Länge modulo 3, mehr nicht.
Die 33 %, die du dafür zahlst
Vier Ausgabezeichen pro drei Eingabebytes bedeutet: Base64-Ausgabe ist rund 33 % größer als die Eingabe. Aus einem 900-KB-Bild werden etwa 1,2 MB Text. Das wiegt genau dort am schwersten, wo am liebsten zu Base64 gegriffen wird: beim Einbetten von Bildern als Data-URI in CSS oder HTML.
Einbetten spart eine HTTP-Anfrage — unter HTTP/1.1 viel wert, unter HTTP/2 und HTTP/3 mit multiplexten Anfragen deutlich weniger. Die Kosten dagegen sind real: Ein eingebettetes Bild lässt sich nicht getrennt vom Dokument cachen, also lädt jede Seitenänderung es erneut, und jeder Besuch lädt es zusammen mit dem HTML. Faustregel: Für winzige Assets — ein Icon von ein paar hundert Byte — ist Einbetten vertretbar, für Fotos ist es ein Fehler.
Base64 ist keine Verschlüsselung
Das ist das mit Abstand häufigste Missverständnis, und es verursacht echte Vorfälle. Base64 hat keinen Schlüssel. Wer die Zeichenkette hat, dekodiert sie in einem Schritt — auch in dem Browser, in dem du das hier liest. Ein Passwort, ein API-Token oder einen Kundendatensatz in Base64 zu kodieren schützt gar nichts: Es macht den Wert nur für einen Menschen unlesbar, der eine Logdatei überfliegt, und das ist keine Sicherheitseigenschaft.
Ein JWT macht es greifbar. Header und Payload sind Base64url, nicht verschlüsselt: Füg eines in einen Decoder ein und du liest jeden Claim darin. Die Signatur verhindert das *Ändern* des Tokens, nicht das *Lesen*. Leg nie etwas in einen JWT-Payload, das der Token-Inhaber nicht sehen soll.
Die URL-sichere Variante
Standard-Base64 nutzt "+" und "/", und beide bedeuten in einer URL etwas anderes: "+" kann im Query-String als Leerzeichen gelesen werden, "/" ist ein Pfadtrenner. Die in RFC 4648 §5 definierte Variante base64url tauscht sie gegen "-" und "_" und lässt das Padding meist weg. Enthält ein Token "-" oder "_" und kein "=", schaust du mit ziemlicher Sicherheit auf base64url — genau das, was JWTs verwenden.
Häufige Fragen
Werden meine Daten an einen Server geschickt?
Nein. Dieses Tool ist als "client" gekennzeichnet: Die Kodierung läuft in deinem Browser-Tab mit dessen eigener JavaScript-Engine, deine Eingabe verlässt das Gerät nie. Tab zu, nichts bleibt übrig. Trotzdem gilt: Sind die Daten wirklich sensibel, nimm ein Werkzeug, das deine Organisation kontrolliert, statt irgendeiner kostenlosen Webseite — auch statt dieser.
Warum zeigt mein dekodierter Text seltsame Zeichen?
Fast immer eine falsche Zeichenkodierung. Base64 kodiert Bytes, keine Zeichen, kann also nicht wissen, ob diese Bytes als UTF-8, Latin-1 oder etwas anderes gemeint waren. War der Originaltext UTF-8 und wird als Latin-1 interpretiert, werden aus Umlauten Paare wie "ä". Der Base64-Schritt ist in Ordnung; die Interpretation danach nicht.
Warum scheitern btoa() und atob() in JavaScript an Umlauten?
Weil sie älter sind als die Unicode-Unterstützung und nur Zeichen im Bereich 0–255 verarbeiten. "ä" an btoa() zu übergeben wirft einen InvalidCharacterError. Die moderne Lösung ist, zuerst mit TextEncoder in Bytes umzuwandeln und dann diese Bytes zu kodieren — genau das macht dieses Tool für dich.
Gibt es eine Größenbeschränkung?
Keine vom Tool auferlegte, aber eine praktische durch dein Gerät. Alles passiert im Arbeitsspeicher, und die kodierte Kopie ist ein Drittel größer als die Eingabe. Sehr große Dateien machen den Tab also träge, bevor überhaupt etwas fehlschlägt. Für Binärdateien im Megabyte-Bereich ist ein Kommandozeilen-Werkzeug das bessere Instrument.