Base64
Du brauchst stattdessen einen einseitigen Fingerabdruck von Daten? Das ist Hashen: siehe den Hash-Generator. Ein JWT-Segment dekodiert und willst es lesbar? Der JSON-Formatierer übernimmt ab da.
Die meisten Tools stützen sich auf btoa des Browsers, das nur Latin-1 akzeptiert und alles andere still beschädigt. Emojis, Akzente und CJK gehen hier exakt hin und zurück.
Base64-Strings tragen API-Schlüssel, Tokens und Zugangsdaten. Diese Seite sendet sie nirgendwohin. Sie funktioniert auch mit ausgeschalteter Verbindung.
Base64 verbirgt nichts. Jeder kann es in einer Sekunde dekodieren, genau wie diese Seite. Nutze es nie, um ein Passwort oder einen Schlüssel zu schützen.
Was ist Base64?
Base64 ist eine Art, beliebige binäre Daten mit nur 64 Zeichen zu schreiben, die überall überleben: A-Z, a-z, 0-9, + und /. Es existiert, weil ein Großteil der Internet-Infrastruktur (E-Mail, URLs, JSON, XML, HTTP-Header) für Text ausgelegt wurde und rohe Bytes bereitwillig beschädigt, entfernt oder ablehnt.
Der Mechanismus ist einfache Arithmetik. Drei Bytes sind 24 Bit; teile diese 24 Bit in vier Gruppen zu je sechs; jede 6-Bit-Gruppe ist eine Zahl von 0 bis 63, die das Alphabet indiziert. Also drei Bytes hinein, vier Zeichen heraus, und dieses Verhältnis ist die ganze Geschichte von Base64, samt seiner 33 % Größenzunahme.
Wofür das Padding da ist
Ist deine Datenmenge kein sauberes Vielfaches von drei Bytes, ist die letzte Gruppe zu kurz. Base64 füllt die Ausgabe mit = auf, sodass die Länge immer ein Vielfaches von vier ist, was einem Decoder sagt, wie viele echte Bytes die letzte Gruppe hielt. Manche Systeme lassen das Padding weg, weil sie die Länge ohnehin kennen. Deshalb gibt es hier den Padding-Schalter, und deshalb sollte ein Decoder es auch ohne akzeptieren. Dieser tut es.
Bytes, nicht Zeichen
Das ist die Feinheit, an der die meisten Implementierungen scheitern. Base64 kodiert Bytes, Text muss also zuerst zu Bytes werden, und das erfordert die Wahl einer Kodierung, praktisch immer UTF-8. Das eingebaute btoa() des Browsers verweigert alles über Latin-1, sodass darauf gebaute Tools entweder abstürzen oder „café“, „日本語“ oder „🎉“ still verstümmeln. Diese Seite konvertiert mit TextEncoder über UTF-8, sodass jedes Alphabet und Emoji den Hin- und Rückweg unversehrt übersteht. Probier es aus.
Base64 ist keine Verschlüsselung
Das verdient einen eigenen Abschnitt, denn es ist das folgenreichste Missverständnis im ganzen Thema, und es taucht in echten Sicherheitsvorfällen auf.
Base64 bietet null Sicherheit. Es gibt keinen Schlüssel, kein Geheimnis und nichts zu knacken. Es ist eine öffentliche, umkehrbare Transformation, die jeder sofort rückgängig machen kann, wie genau diese Seite zeigt. Es macht Daten für einen flüchtigen menschlichen Blick unlesbar, und das ist alles.
Also: Base64e nie ein Passwort und nenne es geschützt. „Verschleiere“ nie einen API-Schlüssel durch Kodieren. Nimm nie an, dass Base64 in einer Konfigurationsdatei, einem Cookie oder einer Datenbankspalte bedeutet, dass der Inhalt sicher ist. Wenn jemand den String lesen kann, kann er die Daten lesen.
Wofür Base64 wirklich da ist, ist der Transport: Bytes einen reinen Textkanal überstehen zu lassen. Verschlüsselung und Kodierung lösen verschiedene Probleme und ergänzen sich gut: zuerst verschlüsseln, dann den Chiffretext base64en, damit er durch E-Mail oder JSON reisen kann. In dieser Reihenfolge fügt die Base64-Schicht der Geheimhaltung nichts und der Kompatibilität alles hinzu.
Du willst den Inhalt eines Tokens prüfen? Ein JWT besteht aus drei URL-sicheren Base64-Segmenten, und du kannst jedes davon hier einfügen.
Wo Base64 auftaucht
| Wo | Sieht aus wie | Hinweise |
|---|---|---|
| Data-URLs | data:image/png;base64,iVBORw0… | Bettet eine Datei direkt in HTML oder CSS ein. Praktisch für winzige Icons; verschwenderisch für alles Größere, da es nicht separat gecacht werden kann |
| HTTP-Basic-Auth | Authorization: Basic dXNlcjpwYXNz | Nur user:password kodiert, überhaupt nicht geschützt, weshalb es HTTPS braucht |
| JSON Web Tokens | eyJhbGciOi… | Drei URL-sichere Segmente, durch Punkte verbunden. Die Payload ist für jeden lesbar; die Signatur macht es vertrauenswürdig |
| E-Mail-Anhänge | MIME, umgebrochen bei 76 Zeichen | Der ursprüngliche Grund, warum Base64 existiert: SMTP war für 7-Bit-Text gebaut |
| Schlüssel und Zertifikate | -----BEGIN CERTIFICATE----- | Das PEM-Format ist Base64 des binären DER, mit Kopfzeilen |
| API-Payloads | Kodierte Blobs innerhalb von JSON | JSON hat keinen Binärtyp, also werden Bytes per Base64 in einen String verwandelt |
Standard vs. URL-sicher
Die + und / von Standard-Base64 sind beide innerhalb einer URL bedeutsam: + kann als Leerzeichen gelesen werden und / als Pfadtrenner. URL-sicheres Base64 (RFC 4648 §5) ersetzt sie durch - und _ und lässt typischerweise auch das =-Padding weg, sodass der String unverändert in einem Query-Parameter oder Pfad stehen kann. Genau das nutzen JWTs. Schalte oben den URL-sicheren Schalter um und beobachte, wie sich die Zeichen ändern. Die zugrunde liegenden Bytes sind identisch.
Du arbeitest eher mit den URLs selbst als mit ihren Payloads? Die Prozent-Kodierung ist ein anderes Schema mit einer anderen Aufgabe.
Häufig gestellte Fragen
Was ist Base64-Kodierung?
Base64 ist eine Art, binäre Daten mit nur 64 reinen Textzeichen zu schreiben: A-Z, a-z, 0-9, Plus und Schrägstrich. Es existiert, weil viele Systeme (E-Mail, URLs, JSON, XML) für Text gebaut wurden und rohe Bytes beschädigen oder ablehnen. Base64 nimmt jeweils drei Bytes und schreibt sie als vier druckbare Zeichen, sodass die Daten jeden Kanal überstehen, der Text transportieren kann.
Ist Base64 eine Verschlüsselung? Ist es sicher?
Nein. Base64 ist keine Verschlüsselung und bietet keinerlei Sicherheit. Es gibt keinen Schlüssel und kein Geheimnis. Jeder kann es sofort dekodieren, genau das tut diese Seite. Es lässt Daten nur für das menschliche Auge verwürfelt aussehen. Nutze Base64 nie, um ein Passwort, einen API-Schlüssel oder persönliche Daten zu verbergen. Brauchst du Geheimhaltung, verschlüssle die Daten; Base64 macht nur einen bereits verschlüsselten Datenblock sicher als Text transportierbar.
Warum macht Base64 meine Daten größer?
Weil es für je drei Bytes vier Zeichen aufwendet, ist die Base64-Ausgabe rund 33 % größer als die Eingabe, plus etwas Padding. Das ist der Preis dafür, nur sichere Zeichen zu nutzen. Deshalb solltest du ein großes Bild nicht per Base64 in eine Webseite packen: Die Bytes sind größer und lassen sich, anders als eine echte Bilddatei, nicht separat vom Browser cachen.
Was ist URL-sicheres Base64?
Standard-Base64 nutzt Plus und Schrägstrich, die beide in einer URL besondere Bedeutungen haben und verstümmelt oder neu kodiert werden. URL-sicheres Base64 (RFC 4648) ersetzt sie durch Minus und Unterstrich und lässt meist auch das Gleichheits-Padding weg. Genau das nutzen JSON Web Tokens für jedes ihrer Segmente. Aktiviere hier die URL-sichere Option und die Ausgabe passt sicher in einen Query-String oder Pfad.
Warum zeigt mein dekodierter Text seltsame Zeichen?
Meist, weil das kodierende Tool UTF-8 falsch behandelt hat. Base64 arbeitet mit Bytes, nicht mit Zeichen, Text muss also zuerst in Bytes umgewandelt werden, und die btoa-Funktion des Browsers akzeptiert nur Latin-1, sodass viele Tools alles jenseits von reinem ASCII still beschädigen. Diese Seite kodiert korrekt über UTF-8, sodass Emojis, Akzente, Griechisch, Arabisch und CJK exakt hin und zurück gehen. Wenn ein Dekodieren hier etwas Seltsames erzeugt, lag der Fehler wahrscheinlich beim ursprünglichen Encoder.
Werden meine Daten beim Kodieren oder Dekodieren hochgeladen?
Nein. Alles wird in deinem Browser mit JavaScript kodiert und dekodiert, auch ganze Dateien, es wird also nichts hochgeladen, protokolliert oder getrackt. Das zählt hier mehr als fast überall: Base64-Strings tragen regelmäßig API-Schlüssel, Tokens und Zugangsdaten, und diese in eine Seite einzufügen, die sie an einen Server sendet, ist ein echtes Leck. Einmal geladen funktioniert diese Seite offline.