Base64-Decoder
Dekodieren Sie beliebige Base64-Strings zurück in lesbaren Text. Der tolerante Decoder akzeptiert Zeilenumbrüche, fehlendes =-Padding und das URL-sichere Alphabet ohne Vorarbeit.
0 Zeichen · 0 Bytes · 0 Zeilen
Ergebnis
0 Zeichen · 0 Bytes · 0 Zeilen
Über die Base64-Dekodierung
Die Dekodierung bildet jede Gruppe von 4 Base64-Zeichen auf die ursprünglichen 3 Bytes ab. Dieser Decoder ist bewusst tolerant: Zeilenumbrüche, streunende Leerzeichen, fehlendes =-Padding und das URL-sichere Alphabet (- und _) werden ohne Vorreinigung akzeptiert.
Häufige Aufgaben: JWT-Payloads inspizieren, API-Tokens prüfen, Data-URLs oder E-Mail-Anhänge ansehen. Dekodierte Bytes werden als UTF-8-Text angezeigt – ein Bild zu dekodieren ergibt Kauderwelsch, das ist normal. Alles läuft lokal; Tokens hier einzufügen ist sicher.
Was dieses Tool abdeckt
Unicode richtig umgesetzt
Text wird vor dem Kodieren in UTF-8-Bytes umgewandelt, sodass 中文, café und 🔒 fehlerfrei hin und zurück konvertiert werden.
Toleranter Decoder
Zeilenumbrüche, überflüssige Leerzeichen, fehlende =-Auffüllung und das URL-sichere Alphabet werden akzeptiert, ohne dass Sie vorher aufräumen müssen.
Nichts verlässt den Tab
Die Kodierung läuft per JavaScript auf Ihrem Gerät. Tokens, Zugangsdaten und Payloads werden nirgendwohin gesendet.
Häufige Fragen
Woran erkenne ich einen Base64-String?
Er nutzt nur A–Z a–z 0–9 + / (bzw. - _ in der URL-sicheren Variante), seine Länge ist ein Vielfaches von 4, und er kann mit einem oder zwei = enden.
Warum ist die dekodierte Ausgabe unleserlich?
Zwei typische Ursachen: Die Originaldaten waren binär (Bild, Archiv) statt Text, oder der Text nutzte eine ältere Kodierung statt UTF-8. Die Dekodierung selbst ist korrekt.
Funktioniert es ohne =-Padding?
Ja. Fehlendes Padding, eingebettete Zeilenumbrüche und das URL-sichere Alphabet werden automatisch verarbeitet.
Ein JWT-Segment scheitert anderswo, klappt aber hier?
JWT nutzt das URL-sichere Alphabet ohne Padding, das viele Decoder ablehnen; dieser akzeptiert es nativ.