Codieren Sie beliebigen Text in Base64 oder decodieren Sie eine Base64-Zeichenkette zurück in Text. Verwenden Sie die URL-sichere Variante, wenn das Ergebnis in eine URL oder einen Dateinamen eingebettet werden muss. Die Konvertierung erfolgt lokal in Ihrem Browser.
Base64 ist eine Binär-zu-Text-Codierung, die beliebige Bytes mit nur 64 druckbaren ASCII-Zeichen darstellt: A-Z, a-z, 0-9, plus + und / (oder - und _ in der URL-sicheren Variante). Es ist die Standardmethode, um Binärdaten — Bilder, Zertifikate, verschlüsselte Blobs — in textbasierten Formaten wie JSON, XML, E-Mail oder HTTP-Headern einzubetten.
Die Codierung vergrößert die Daten um genau 4/3 (33 %): Aus jeweils drei Bytes Eingabe werden vier Ausgabe-Zeichen. Die Codierung ist vollständig reversibel, das Decodieren liefert die ursprünglichen Bytes byteweise zurück. Die URL-sichere Variante ersetzt + und / durch - und _, um URL-Codierungsregeln nicht zu verletzen.
Dieses Tool verarbeitet derzeit nur Text. Drag-and-Drop für Dateien ist auf der Roadmap. Als Workaround fügen Sie die Dateiinhalte ein (z. B. über xxd) oder verwenden Sie ein Desktop-Tool wie base64.
Ja. Die Eingabe wird zuerst als UTF-8-Bytes codiert, dann werden diese Bytes Base64-codiert. Emojis, Akzente und CJK-Zeichen überstehen Codieren + Decodieren korrekt.
Standard-Base64 verwendet + und /, beide sind in URLs reserviert. Die URL-sichere Variante (RFC 4648 §5) ersetzt sie durch - und _ und entfernt das nachgestellte =-Padding. Verwenden Sie diese Variante für URLs, Dateinamen oder JWT-Segmente.
Base64 codiert drei Eingabe-Bytes in vier Ausgabe-Zeichen, das Ergebnis ist also immer ~33% größer. Dieser Mehraufwand ist der Preis für ein textsicheres Alphabet. Wenn Größe wichtig ist (große Anhänge, Payload-Limits), ist Base64 das falsche Werkzeug — komprimieren Sie die Daten zuerst mit gzip oder zstd, oder senden Sie rohe Bytes über einen binärfähigen Kanal.
Nein. Base64 ist eine Codierung, keine Verschlüsselung. Jeder kann sie sofort ohne Schlüssel decodieren — kein Geheimnis ist beteiligt. Wenn Sie Vertraulichkeit benötigen, verwenden Sie eine echte Chiffre (AES-GCM, ChaCha20-Poly1305) und codieren Sie nur den resultierenden Geheimtext in Base64, falls Sie ihn in JSON oder eine URL einbetten müssen.
Wo Base64 in der täglichen Web-Arbeit immer wieder auftaucht.
JWTs sind drei durch Punkte getrennte Base64URL-Blöcke. Fügen Sie den mittleren Block ein, um die Claims zu dekodieren und Benutzer, Ablauf oder Scopes zu prüfen.
Authorization: Basic <Base64(user:pass)> — fügen Sie den Suffix ein, um die durch Doppelpunkt getrennten Anmeldedaten zurückzugewinnen, hilfreich beim Debuggen vorgelagerter Dienste.
Codieren Sie ein winziges PNG oder SVG, um es direkt in HTML oder CSS zu inlinen, eine HTTP-Anfrage einsparend, zum Preis von ~33 % mehr Bytes.
JSON kann keine Rohbytes tragen. Base64-codieren Sie das Blob, senden es als String und decodieren auf der Empfängerseite — üblich für Datei-Uploads in REST-APIs.
Die richtige Variante für die richtige Aufgabe.
+ und / sind in URLs reserviert und in Dateinamen unsicher. Die URL-safe-Variante (- und _, ohne Padding) umgeht beide Probleme.
Base64 bläht um 33 % auf. Wenn Größe wichtig ist, erst gzip oder brotli, dann Base64 — die Kompression schlägt meist den Codierungsaufschlag.
Base64 ist ohne Schlüssel vollständig umkehrbar. Verwenden Sie es niemals als Geheimnis-Notbehelf; kombinieren Sie es mit einer echten Chiffre, wenn Vertraulichkeit zählt.
JWT und viele URL-safe-Kontexte entfernen das nachgestellte =-Padding. Die meisten Decoder akzeptieren Eingabe mit oder ohne, also nicht aufgrund von Länge mod 4 ablehnen.