Base64 Dekoder
Dekodieren Sie Base64-kodierte Strings zurück in ihre ursprüngliche Klartext- oder binäre Darstellung. Unterstützt sowohl das Standard-RFC 4648 als auch die URL-sicheren Base64-Alphabete, einschließlich JWT-Token.
Base64-Strings sind absichtlich undurchsichtig - SGVsbG8sIFdvcmxkIQ== ist bedeutungslos, bis es zurück zu Hallo, Welt! dekodiert wird. Definiert in RFC 4648, kodiert Base64 jedes 3 Eingabebyte als 4 Ausgabewerte und fügt ungefähr 33% Overhead hinzu. Dieser Dekoder kehrt das mit den nativen atob() und TextDecoder APIs des Browsers um. Er unterstützt sowohl Standard Base64 als auch die URL-sichere Variante (- und _ anstelle von + und /), die in JWTs und OAuth-Token verwendet wird. Nichts wird an einen Server hochgeladen.
So dekodieren Sie Base64
- Fügen Sie Ihren Base64-kodierten String in das Eingabefeld ein.
- Wählen Sie den Standard oder URL-sicheren Modus, um zu entsprechen, wie die Daten ursprünglich kodiert wurden.
- Der dekodierte Klartext erscheint sofort im Ausgabefeld.
- Klicken Sie auf Kopieren, um das Ergebnis zu kopieren.
Wie die Base64-Dekodierung funktioniert
Der Dekodierungsprozess
Das Dekodieren kehrt das Kodieren genau um. Jedes Base64-Zeichen wird mit Hilfe der Alphabet-Tabelle auf seinen 6-Bit-Wert zurückgemappt. Vier aufeinanderfolgende Zeichen (24 Bit) rekonstruieren drei Bytes. Die atob()-Funktion des Browsers verarbeitet Standard Base64 nativ. Für URL-sichere Base64 werden - und _ vor dem Dekodieren wieder in + und / umgewandelt. Die resultierende UTF-8-Byte-Sequenz wird dann mit TextDecoder in einen Unicode-String dekodiert.
Umgang mit fehlendem Padding
Standard Base64 benötigt =-Padding, um die Stringlänge ein Vielfaches von 4 zu machen. JWTs und OAuth-Token entfernen Padding, um die Größe zu reduzieren. Dieser Dekoder berechnet und fügt automatisch das erforderliche Padding basierend auf der Stringlänge hinzu. Wenn die Stringlänge mod 4 2 ist, wird ein = benötigt; wenn es 3 ist, werden zwei =-Zeichen benötigt.
Beispiel
Eingabe (Standard Base64)
SGVsbG8sIFdvcmxkIQ==Ausgabe
Hallo, Welt!Häufige Anwendungsfälle
- JWT-Token-Inspektion - Dekodieren Sie die Header- und Payload-Abschnitte, um Ansprüche ohne Bibliothek zu lesen
- HTTP Basic Auth - Dekodieren Sie
Authorization: Basic dXNlcjpwYXNz-Header, um eingebettete Anmeldedaten zu überprüfen - Daten-URI-Inspektion - Dekodieren Sie den Base64-Teil von
data:image/png;base64,...URIs - API-Antwort-Debugging - Einige APIs kodieren binäre Inhalte in JSON-Antworten mit Base64
Best Practices
- Wählen Sie den richtigen Modus (Standard vs URL-sicher) - die Verwendung des falschen Modus führt zu unleserlicher Ausgabe
- Für JWT-Token dekodieren Sie nur den Header (erster Teil) und den Payload (zweiter Teil); der dritte Teil ist eine kryptografische Signatur, kein kodierter Text
- Wenn die Ausgabe unleserliche Zeichen enthält, waren die Quelldaten binär (Bild, PDF usw.), nicht Text
- Base64-Dekodierung ist kein Sicherheitscheck - jeder kann es dekodieren
Um Text wieder in Base64 zu kodieren, verwenden Sie den Base64 Encoder. Für URL-kodierte Daten verwenden Sie den URL Decoder. Um ein JWT vollständig zu inspizieren, dekodieren Sie die ersten beiden durch Punkte getrennten Teile separat mit ausgewähltem URL-sicheren Modus.
Häufig gestellte Fragen
Wie dekodiere ich ein JWT-Token mit diesem Tool?
Ein JWT besteht aus drei Teilen, die durch Punkte getrennt sind: header.payload.signature. Kopieren Sie den Header (erster Teil) oder den Payload (zweiter Teil), wählen Sie den URL-sicheren Modus und fügen Sie ihn in den Dekoder ein. Das Ergebnis ist das JSON-Objekt mit dem Algorithmus (Header) oder den Ansprüchen (Payload). Dekodieren Sie nicht die Signatur - sie ist ein kryptografischer Hash, kein Base64-kodierter JSON-String.
Warum zeigt meine dekodierte Ausgabe seltsame Zeichen an?
Das bedeutet eines von drei Dingen: (1) Die ursprünglichen Daten waren binär (Bild, PDF, Zip) statt Text; (2) Sie haben den falschen Modus ausgewählt - versuchen Sie, zwischen Standard und URL-sicher zu wechseln; (3) Der ursprüngliche Text wurde mit einem anderen Zeichensatz als UTF-8 kodiert. Versuchen Sie zuerst, die Modi zu wechseln. Wenn die Ausgabe weiterhin unleserlich ist, waren die Quelldaten wahrscheinlich binär.
Brauche ich die Padding-Zeichen (==), damit das Dekodieren funktioniert?
Standard Base64 benötigt Padding, um die Stringlänge ein Vielfaches von 4 zu machen. Dieser Dekoder fügt automatisch fehlendes Padding hinzu, was wichtig für JWT- und OAuth-Token ist, die abschließende =-Zeichen entfernen. Fügen Sie den String so ein, wie er ist, und der Dekoder kümmert sich automatisch um das Padding.
Sind meine sensiblen Daten beim Dekodieren hier sicher?
Ja. Das Dekodieren erfolgt vollständig in Ihrem Browser unter Verwendung der nativen atob() und TextDecoder APIs. Tokens, Anmeldedaten und private Daten, die Sie einfügen, werden niemals an einen Server gesendet, niemals protokolliert und niemals gespeichert. Öffnen Sie den Netzwerk-Tab des Browsers während des Dekodierens, und Sie werden keine ausgehenden Anfragen sehen.
Was ist der Unterschied zwischen Standard und URL-sicherem Base64?
Standard Base64 (RFC 4648 §4) verwendet + und /. URL-sichere Base64 (RFC 4648 §5) ersetzt diese durch - und , um Konflikte in URLs, Dateinamen und HTTP-Headern zu vermeiden. JWTs, OAuth-Token und PKCE-Code-Überprüfer verwenden alle URL-sichere Base64. Wenn Ihr String - oder enthält, wählen Sie den URL-sicheren Modus.