Base64-Kodierer / -Dekodierer
Kodieren und dekodieren Sie Base64, Base64URL, Base32 und Hex — Text live beim Tippen, Dateien per Drag & Drop — mit einem Dekodierer, der streng genug ist, Ihnen die genaue Position des ersten Zeichens zu nennen, das nicht dazugehört, statt nur mit den Schultern zu zucken. Alles läuft in Ihrem Browser: Die Zeichenfolgen, die Menschen dekodieren, sind so oft Tokens und Geheimnisse, dass sie an einen Server zu senden — oder in einen protokollierten KI-Chat einzufügen — genau das ist, was ein Dekodierer niemals von Ihnen verlangen darf.
Dateien
Ziehen Sie eine Datei irgendwo in dieses Feld, um sie im oben gewählten Format zu kodieren — Sie erhalten den kodierten Text und eine fertige Data-URL. Oder fügen Sie hier kodierten Text ein und laden die dekodierten Bytes als Datei herunter.
Vier Alphabete, eine Aufgabe
Alle vier Formate tun dasselbe — beliebige Bytes nur mit sicheren, druckbaren Zeichen schreiben — für unterschiedliche Zwecke. Standard-Base64 ist der Standard für E-Mail-Anhänge, Konfigurationsdateien und tausende APIs. Base64URL tauscht die zwei Zeichen, die eine URL brechen würden (+ und /), gegen - und _, lässt die Füllzeichen weg und ist das Alphabet in jedem JSON Web Token — dekodieren Sie einen mit dem JWT-Dekodierer, und alle drei Segmente sind in diesem Format. Base32 nutzt ein kleineres, groß-/kleinschreibungsunabhängiges Alphabet, das Vorlesen und Abtippen übersteht — deshalb werden TOTP-Geheimnisse für Authenticator-Apps darin ausgegeben. Hex verdoppelt die Größe und kauft dafür totale Transparenz: ein Byte, zwei Zeichen, nichts verborgen — das Format von Hashes, die der Hash-Generator erzeugt und der Hash-Erkenner erkennt.
Die Strenge ist Absicht, und sie ist der Unterschied zwischen einem Dekodierer und einem Debugging-Werkzeug. Browser-Einbauten wie atob() werfen einen einzigen generischen Fehler — für eine Zeichenfolge mit einem Tippfehler an Position 4 genauso wie für eine, die überhaupt kein Base64 ist. Dieser Dekodierer prüft Zeichen für Zeichen und meldet die erste fehlschlagende Position — ein aus JSON mitgeschlepptes Anführungszeichen, ein + an der Stelle, an der das URL-sichere Alphabet hingehört, Füllzeichen in der Mitte oder ein letztes Zeichen, dessen überschüssige Bits nicht null sind, was bedeutet, dass die Zeichenfolge nach dem Kodieren verändert wurde. Neunzig Prozent aller „lässt sich nicht dekodieren“-Rätsel werden an genau dieser einen Position sichtbar, sobald jemand darauf zeigt. Und weil es bei dieser Arbeit so oft um Zugangsdaten geht — ein Kubernetes-Geheimnis ist Base64 (eine Kodierung, niemals eine Verschlüsselung), eine Token-Nutzlast, ein Schlüssel in einer Konfigurationsdatei —, läuft die gesamte Umwandlung lokal, nach derselben Regel wie beim .env-Prüfer: Sensible Eingaben werden nie übertragen. Der Begleitartikel Base64 ist keine Verschlüsselung führt ausführlich aus, warum dieser Unterschied zählt.
Häufige Fragen
Ist Base64 eine Form der Verschlüsselung?
Nein. Base64 ist eine Kodierung — ein umkehrbarer Kostümwechsel ohne Schlüssel und ohne Geheimhaltung. Jeder, der eine Base64-Zeichenfolge sieht, kann sie sofort dekodieren; deshalb bedeutet „der API-Schlüssel steht Base64-kodiert in der Konfiguration“, dass der API-Schlüssel faktisch im Klartext in der Konfiguration steht. Der Artikel Base64 ist keine Verschlüsselung entwirrt Kodierung, Verschlüsselung und Hashing — und die Fehler, die jede Verwechslung produziert.
Warum nennt mir dieser Dekodierer die genaue Position eines Fehlers?
Weil „ungültiges Zeichen“ ohne Position die Art ist, wie generische Dekodierer Ihnen den Nachmittag verderben. Eingefügte Zeichenfolgen scheitern meist aus einem von drei Gründen: ein verirtes Zeichen aus dem umgebenden Text (ein Anführungszeichen, ein Komma, eine Zeile eines Logs), das falsche Alphabet (eine URL-sichere Zeichenfolge in einem Standard-Dekodierer) oder eine abgeschnittene Kopie. Hier wird das erste beanstandete Zeichen mit seinem Index benannt, sodass Sie genau diese Stelle ansehen und erkennen können, welcher der drei Fälle eingetreten ist.
Was ist der Unterschied zwischen Base64 und Base64URL?
Das Alphabet. Standard-Base64 verwendet + und /, die in URLs Strukturzeichen sind; URL-sicheres Base64 tauscht sie daher gegen - und _ und lässt meist die =-Füllzeichen weg. Das ist die Variante in jedem JWT. Eine Variante in den Dekodierer der anderen zu füttern, ist die häufigste Ursache für einen Dekodierfehler an der Position des ersten + oder / — dieses Werkzeug hält die Modi getrennt, damit die Fehlermeldung Ihnen sagen kann, dass genau das passiert ist.
Ist es sicher, hier ein Token oder ein Geheimnis zu dekodieren?
Ja — die Umwandlung läuft in Ihrem Browser, auf dieser Seite, und nichts, was Sie einfügen, wird übertragen oder gespeichert. Das zählt, weil die Dinge, die Menschen dekodieren, so oft Zugangsdaten sind: ein Base64-Block in einer Konfigurationsdatei, ein Kubernetes-Geheimnis (das ist Base64, keine Verschlüsselung — siehe die Frage oben), die Nutzlast eines Tokens. Dieselbe Zeichenfolge in einen KI-Chat einzufügen, sendet eine Kopie an ein protokollierendes Drittsystem; siehe Lassen Sie niemals einen Chatbot an Ihre Geheimnisse.
Warum wurde meine Datei als „kein gültiges UTF-8“ dekodiert?
Weil sie binär ist — ein Bild, ein Archiv, irgendetwas Kompiliertes — und Binärdaten sind kein Text. Der Text-Dekodierer verweigert sich, statt Ihnen Zeichensalat zu übergeben. Verwenden Sie den Datei-Bereich unter den Textfeldern: Fügen Sie das Base64 dort ein und laden Sie die rekonstruierte Datei mit intakten Bytes herunter.