Online-Werkzeug zum Kodieren und Dekodieren von Base64

1. 1

   Richtung wählen

   Kodieren wandelt Inhalt in Base64 um, Dekodieren holt den ursprünglichen Text oder die ursprüngliche Datei aus einer Base64-Zeichenkette zurück.

2. 2

   Eingabe liefern

   In das Feld tippen oder einfügen, oder eine Datei ablegen. Kodieren nimmt jede Datei; Dekodieren nimmt Textdateien mit Base64, auch PEM-Zertifikate mit ihren BEGIN- und END-Zeilen.

3. 3

   Format festlegen

   Standard- oder URL-sicheres Alphabet wählen, entscheiden ob die Füllzeichen bleiben, auf 64 oder 76 Zeichen umbrechen, und die Daten-URI-Option einschalten, wenn das Ergebnis in HTML oder CSS geht.

4. 4

   Ergebnis prüfen

   Getippter Text wird laufend umgewandelt. Das Panel nennt Eingabegröße, Ausgabegröße und Overhead, und beim Dekodieren zusätzlich das erkannte Alphabet, die verwendete Textkodierung und den gefundenen Dateityp.

5. 5

   Kopieren oder herunterladen

   Ergebnis in die Zwischenablage kopieren, unter einem Namen herunterladen, der zum tatsächlichen Inhalt passt, oder einen ganzen Stapel als ein ZIP holen. Nichts verlässt zu irgendeinem Zeitpunkt dein Gerät.

Neun Einstellungen, und jede existiert, weil ein echtes Format sie braucht. Hier steht, was jede ändert und wann das zählt.

Standard- und URL-sicheres Alphabet

Base64 braucht vierundsechzig druckbare Zeichen. Zweiundfünfzig Buchstaben und zehn Ziffern ergeben zweiundsechzig, und über die letzten beiden sind sich die Varianten uneins. Das Standardalphabet aus RFC 4648 Abschnitt 4 nutzt Plus und Schrägstrich, richtig für Nachrichtentexte und API-Felder. Die URL-sichere Variante aus Abschnitt 5 nutzt stattdessen Bindestrich und Unterstrich, weil ein Schrägstrich einen Pfad teilt und ein Plus in einem Query-String ein Leerzeichen bedeutet. Alles andere ist identisch, und deshalb wird eine Nutzlast aus reinen Buchstaben und Ziffern von beiden gleich dekodiert.

Füllzeichen, und wann man sie weglässt

Base64 arbeitet in Dreiergruppen von Bytes, eine Nutzlast, deren Länge kein Vielfaches von drei ist, endet also mit einer unvollständigen Gruppe. Die Gleichheitszeichen sagen, wie unvollständig. Standard-Base64 behält sie, URL-sicheres Base64 meist nicht, weil ein JSON Web Token drei Base64-Segmente durch Punkte getrennt aneinanderreiht und Füllzeichen dabei stören. Weglassen verliert nichts: Der Decoder kann aus der Länge allein ableiten, wie viele Bytes die letzte Gruppe trägt, und deshalb ergänzt dieses Werkzeug die Füllzeichen für dich, wenn du eine Zeichenkette ohne sie einfügst.

Zeilenumbruch für PEM und MIME

Zwei Formate verlangen Zeilenumbrüche innerhalb der Nutzlast. PEM, definiert in RFC 7468, bricht bei vierundsechzig Zeichen um, und OpenSSL lehnt ein Zertifikat ab, das als eine lange Zeile ankommt. MIME, definiert in RFC 2045 Abschnitt 6.8, verlangt Zeilen von höchstens sechsundsiebzig Zeichen im Nachrichtentext, auch weil ältere Transportwege eigene Umbrüche einfügten und die Nutzlast dabei zerstörten. Voreingestellt ist hier kein Umbruch, denn die beiden anderen großen Abnehmer von Base64 — ein Daten-URI und ein JSON-Feld — brauchen eine einzige durchgehende Zeile, und ein Umbruch in einem Daten-URI verhindert das Laden.

Jede Zeile einzeln kodieren

Manchmal hat man keine Nutzlast, sondern eine Liste: eine Spalte von Werten, ein Satz Zugangsdaten, ein Datensatz pro Zeile. Den ganzen Block zu kodieren ergibt eine Zeichenkette, die man dekodieren und wieder aufteilen muss. Jede Zeile einzeln zu kodieren ergibt einen Base64-Wert pro Zeile, fertig zum Einfügen in eine Spalte. Windows-Zeilenenden sind berücksichtigt: Der Wagenrücklauf gilt als Teil des Umbruchs und nicht als letztes Zeichen der Zeile — ein Unterschied, den man erst später bemerken würde, als unsichtbares Zeichen am Ende jedes dekodierten Werts.

Strenge Prüfung

Das meiste Base64, das bei einem Menschen ankommt, hat etwas durchlaufen: einen Chat, der ein Anführungszeichen ergänzte, ein Dokument, das einen Bindestrich in einen Gedankenstrich verwandelte, ein Terminal, das eine Zeile umbrach. Nachsichtiges Dekodieren ignoriert, was nicht zum Alphabet gehört, und ergänzt fehlende Füllzeichen — meistens genau richtig. Die strenge Prüfung ist für die Fälle, in denen du wissen musst, dass die Nutzlast exakt die erzeugte ist: Sie lehnt unbekannte Zeichen ab, lehnt Füllzeichen in der Mitte ab und lehnt ein letztes Zeichen ab, dessen Restbits nicht null sind — der einzige Fehler, der sonst völlig unsichtbar bleibt, weil diese Bits ohnehin verworfen werden.

Textkodierungen auf dem Rückweg

Dekodieren liefert Bytes, und Bytes in lesbaren Text zu verwandeln ist eine zweite Entscheidung, die das Werkzeug richtig treffen muss. Lies eine Windows-1252-Nutzlast als UTF-8, und jedes typografische Anführungszeichen wird zum Ersatzzeichen; lies UTF-16 als UTF-8, und du bekommst ein NUL zwischen jedem Buchstaben. Sieben Kodierungen stehen zur Wahl, dazu eine automatische Erkennung, die zuerst eine Byte-Order-Mark liest, dann die Bytes gegen die UTF-8-Regeln prüft, dann nach dem dichten einseitigen NUL-Muster sucht, das nur UTF-16 erzeugt, und erst dann auf Windows-1252 ausweicht — das zuletzt steht, weil es als einziges der acht jede beliebige Bytefolge dekodieren kann, sodass alles danach nie an die Reihe käme.

Base64 bringt binäre Nutzlasten durch Systeme, die nur reinen Text vertragen, hält Konfiguration portabel und passt gut zu APIs und Markup, die kleine Ressourcen einbetten. Kodiere Text nach Base64 oder dekodiere ihn zurück, aus Text oder aus Dateien, mit Live-Konvertierung während der Eingabe.

Wofür Base64 gut ist

• Transport: Bytes sicher über E-Mail, JSON, XML oder Logs bewegen, ohne Zeilenenden zu zerstören.
• Einbetten: Winzige Bilder oder Schriften als Daten-URI einbetten, wenn eine separate Datei unpraktisch ist.
• Interoperabilität: Dieselbe ASCII-sichere Darstellung über Windows, macOS, Linux und das Web teilen.
• Speicherung: Undurchsichtige Blobs in textorientierten Speichern ablegen, wenn es keine Binärspalten gibt.
• Fehlersuche: API-Antworten oder Zertifikate während der Entwicklung als lesbare Zeichenketten prüfen.
• Tokens: Kopf und Nutzlast eines JSON Web Tokens lesen — beides URL-sicheres Base64 ohne Füllzeichen.

Deine Bytes werden in Sechs-Bit-Gruppen zerlegt; jede Gruppe steht für ein Zeichen des Alphabets, und Füllzeichen halten die Länge auf einem Vielfachen von vier Zeichen.

Der Kodierweg

• Eingabe: Text wird in der gewählten Kodierung zu Bytes; Dateien sind bereits Bytes und werden direkt gelesen.
• Bitgruppierung: Der Bytestrom wird so zerlegt, dass jeder Index eines von vierundsechzig Symbolen wählt.
• Füllzeichen: Abschließende = markieren, wann der letzte Block Füllbits brauchte.
• Formatierung: Das Ergebnis bleibt einzeilig, wird auf 64 oder 76 Zeichen umgebrochen oder als Daten-URI umschlossen.
• Ausgabe: Du bekommst Text zum Einfügen in Code, eine Konfigurationsdatei, ein Stylesheet oder eine API-Anfrage.
• Dekodieren: Die Schritte laufen rückwärts und liefern die ursprüngliche Bytefolge, die dann als Text gelesen oder als Datei zurückgegeben wird.

Ein Daten-URI trägt eine ganze Datei in einer einzigen Zeichenkette, sodass ein kleines Bild, ein Symbol oder eine Schrift im HTML oder Stylesheet leben kann, das sie benutzt, statt in einer eigenen Anfrage. Es ist der häufigste Grund, überhaupt einen Base64-Encoder zu öffnen.

Der Aufbau eines Daten-URI

Die Grammatik lautet data:, dann ein optionaler Medientyp, dann optionale Parameter, dann ein Komma, dann die Nutzlast. Ist die Nutzlast Base64, steht das Wort base64 direkt vor dem Komma. Der Medientyp zählt mehr, als es aussieht: Ein Daten-URI ohne ihn gilt als reiner Text, ein PNG ohne Typ erscheint also in einem img-Tag als kaputtes Bild und in CSS als gar nichts. Dieses Werkzeug schreibt den Medientyp immer und leitet ihn aus den Signaturbytes der Datei ab, wenn die Datei ihn selbst nicht angibt.

Wann einbetten und wann nicht

Einbetten spart eine Anfrage, was sich für etwas Winziges lohnt, das sofort gebraucht wird: ein Logo in einer E-Mail-Vorlage, ein Symbol in einem Stylesheet, ein Platzhalter in einem Testdatensatz. Es lohnt sich schnell nicht mehr. Base64 fügt rund ein Drittel Größe hinzu, eine eingebettete Ressource lässt sich nicht getrennt vom tragenden Dokument zwischenspeichern, und ein großer Daten-URI macht das Dokument selbst langsamer zu verarbeiten. Als Faustregel: einbetten, was in Kilobyte gemessen wird, und hosten, was in Hunderten von Kilobyte gemessen wird.

Sobald eine Base64-Zeichenkette in einer URL reisen muss, wird das Standardalphabet zum Problem, und die Lösung ist eine Variante, die seit 2006 im Standard steht.

Warum Plus und Schrägstrich in einer URL zerbrechen

Ein Schrägstrich trennt Pfadsegmente, eine Nutzlast mit einem darin wird also als zwei Segmente gelesen. Ein Plus wird in einem Query-String seit jeher als Leerzeichen dekodiert, eine Nutzlast mit einem darin kommt also verändert zurück. Ein Gleichheitszeichen trennt einen Parameter von seinem Wert. Alle drei kommen in gewöhnlicher Base64-Ausgabe vor, und deshalb definiert RFC 4648 Abschnitt 5 die URL-sichere Variante: Bindestrich statt Plus, Unterstrich statt Schrägstrich, und Füllzeichen, die man weglassen darf.

Ein JSON Web Token lesen

Ein JWT besteht aus drei URL-sicheren Base64-Segmenten, durch Punkte getrennt, ohne Füllzeichen. Füge ein Segment hier ein, und es wird ohne Einstellungsänderung dekodiert, weil das Alphabet aus der Zeichenkette erkannt und das fehlende Füllzeichen ergänzt wird. Kopf und Nutzlast sind lesbares JSON. Die Signatur ist nicht zum Lesen gedacht und kommt als Bytes zurück — dekodiere sie zu einer Datei statt zu Text, sonst sieht es nach einem Dekodierfehler aus, obwohl keiner vorliegt. Base64 ist keine Verschlüsselung und die Nutzlast eines JWT ist nicht geheim: Wer das Token hat, kann sie genau so lesen, wie du es gerade getan hast.

Die meisten gemeldeten Base64-Probleme sind keine Probleme mit Base64. Es ist eine Zeichenkette, die unterwegs etwas durchlaufen hat, und das Nützlichste, was ein Werkzeug tun kann, ist zu sagen, was.

Die Fehler, die man kennen sollte

Eine Länge, die ein Zeichen übrig lässt, kann überhaupt kein Base64 sein — keine Bytefolge kodiert dazu — es ist also fast immer ein beim Kopieren verlorenes Zeichen. Füllzeichen in der Mitte bedeuten meist, dass zwei Nutzlasten aneinandergehängt wurden. Zeichen außerhalb des Alphabets sind meist Satzzeichen, die ein Chat oder eine Textverarbeitung eingebracht hat, und das geschützte Leerzeichen ist das gemeinste, weil es unsichtbar ist. Eine Mischung aus Plus-Schrägstrich und Bindestrich-Unterstrich heißt, dass ein Suchen-und-Ersetzen über die halbe Zeichenkette lief. Ein letztes Zeichen mit Restbits ungleich null heißt, dass die Zeichenkette nach dem Kodieren verändert wurde, und es ist das einzige dieser Probleme ohne sichtbares Symptom, weil diese Bits beim Dekodieren ohnehin verworfen werden.

Gewohnheiten, die all das vermeiden

Kopiere aus einer Klartextansicht statt aus einer gerenderten. Entscheide einmal, ob deine API Standard- oder URL-sicheres Base64 erwartet, und schreibe es dorthin, wo die Aufrufenden es sehen. Wenn eine Nutzlast einen Nachrichtentext oder eine Zertifikatsdatei überstehen muss, brich sie so um, wie das Format es verlangt, statt zu hoffen, dass niemand die Zeile für dich bricht. Und wenn doch etwas schiefgeht, sieh zuerst auf die Länge: eine Sekunde Prüfung, die die Hälfte der Möglichkeiten ausschließt.

Wer den Größen-Overhead und den Unterschied zur Verschlüsselung kennt, vermeidet falsche Erwartungen in Produktivsystemen.

Kurzübersicht

• Rechne mit rund dreiunddreißig Prozent mehr Größe gegenüber dem rohen Binärinhalt derselben Nutzlast.
• Das MIME-Alphabet nutzt A–Z, a–z, 0–9 sowie + und /; URL-sichere Varianten tauschen die Symbole, folgen aber derselben Idee.
• Füllzeichen halten Decoder ausgerichtet, wenn die Byteanzahl nicht durch drei teilbar ist.
• Base64 ist bei Standardalphabeten umkehrbar und deterministisch, und genau deshalb darf es Verschlüsselung nie ersetzen.
• Sehr große Dateien werden zu sehr langen Zeichenketten; Browser wirken dann langsamer, einfach weil die Zeichenkette riesig ist.
• Vier Base64-Zeichen tragen immer genau drei Bytes, du kannst die dekodierte Größe also ausrechnen, bevor du irgendetwas dekodierst.

Bewährte Vorgehensweisen

Nimm das richtige Werkzeug: Base64 für Transport und Einbettung, Verschlüsselung für Vertraulichkeit, Kompression vor dem Kodieren, wenn Bandbreite zählt.

• Prüfe die dekodierte Ausgabe in einer Testumgebung, bevor du automatisierten Abläufen vertraust.
• Entferne Leerraum aus eingefügten Zeichenketten, wenn du aus formatierten Dokumenten kopiert hast.
• Nutze für große Medien lieber dediziertes Hosting statt riesiger Daten-URIs.
• Halte fest, ob deine API Standard- oder URL-sicheres Base64 erwartet, um subtile Fehler zu vermeiden.
• Speichere Passwörter oder Geheimnisse nie nur hinter Base64 — Angreifende dekodieren das sofort.
• Komprimiere vor dem Kodieren, nie danach: Base64-Ausgabe ist Text und komprimiert weit schlechter als die Bytes, aus denen sie stammt.

Typische Anwendungsfälle

• Webentwicklung: Mit Daten-URIs experimentieren oder API-Antworten mit binären Proben nachbilden.
• Automatisierung: Nutzlasten für Skripte vorbereiten, die nur Texteingabe annehmen.
• E-Mail und MIME: Anhänge verstehen, die historisch für Sieben-Bit-SMTP-Wege kodiert wurden.
• Konfiguration: Kurze Schlüssel oder Prüfsummen in .env-freundlichen Dateien serialisieren.
• Lehre: Zeigen, wie sich Darstellungsschichten über rohe Bits legen.
• Zertifikate: Einen PEM-Block ohne Kommandozeile lesen — mit BEGIN- und END-Zeilen einfügen.

Beide Richtungen nehmen Dateien an, was ungewöhnlich ist: Die meisten Base64-Werkzeuge kodieren eine Datei und zwingen dich dann, für den Rückweg Text einzufügen.

Welche Dateien jede Richtung annimmt

Kodieren nimmt alles, denn Base64 ist über beliebige Bytes definiert und es gibt keine Datei, die es nicht darstellen kann. Dekodieren nimmt Dateien, deren Inhalt Base64-Text ist — .txt, .b64, .pem, .crt, .key und die übrigen Klartext-Endungen — und lehnt den Rest schon beim Auswählen ab, mit einem Link zum Richtungswechsel, statt ihn anzunehmen und später zu scheitern. Nach dem Dekodieren werden die Bytes über ihre eigenen magischen Zahlen bestimmt, ein dekodiertes PNG kommt also als .png und ein dekodiertes PDF als .pdf zurück.

Was der kostenlose Tarif umfasst und was Pro ergänzt

Der kostenlose Tarif wandelt eine Datei nach der anderen um, bis 25 MB. Das ist eine Tarifentscheidung und keine Grenze des Geräts: Eine 25-MB-Datei wird hier in wenigen Hundertstelsekunden kodiert, und die Arbeit berührt die Seite, die du ansiehst, nie. Pro stellt bis zu hundert Dateien in die Warteschlange, wandelt sie nacheinander um und gibt sie als ein einziges ZIP zurück, in dem doppelte Namen eindeutig gemacht werden — was mehr zählt, als es klingt, denn zwei Dateien namens foto.png aus verschiedenen Ordnern würden sonst zu einem Eintrag, und das Archiv enthielte stillschweigend weniger Dateien, als du umgewandelt hast.

Base64 ist eine Darstellung, keine Kompression und kein Schutz. Es vergrößert Daten, jede und jeder kann es trivial umkehren, und es sollte nie das Einzige sein, was zwischen einem Geheimnis und der Person steht, die deine Konfigurationsdatei liest. Es kann auch keine Daten reparieren, die schon vor dem Kodieren falsch waren.

Alles läuft auf deinem Gerät. Die Umwandlung geschieht abseits der Seite, das Tippen bleibt also flüssig, wie groß die Nutzlast auch ist, und eine 25-MB-Datei wird in einem aktuellen Desktop-Browser in etwa fünfzehn Tausendstelsekunden umgewandelt. Es wird nichts hochgeladen, und das Werkzeug arbeitet ohne Netzwerkverbindung weiter, sobald die Seite geladen ist.

• Base64-Encoder
• Base64-Decoder
• URL-Encoder/Decoder
• Alle Konverter
• Hash-Generator
• UUID-Generator
• JSON-Formatierer
• QR-Code-Generator
• QR-Code-Leser
• Farbkonverter
• Bild vorher komprimieren
• Favicon-Generator
• JSON escapen
• JSON-Minifizierer
• Text-Trimmer
• Alle Textwerkzeuge