Zerlegt ein dreiteiliges JSON Web Token in UTF-8-JSON-Objekte, erklärt registrierte/eigene Claims und Zeiten und zeigt Signaturbytes, ohne Vertrauen vorzutäuschen. Ideal für Backend-Entwickler und DevOps-Ingenieure, die JWT-Inhalte debuggen, Tokenstruktur analysieren und Ablaufzeiten prüfen wollen, ohne die Signatur zu verifizieren.
JWT-Werkzeuge
JWT-Token
Drag-and-Drop unterstützt
Warte auf Eingabe. Wählen Sie einen Demo-Token, um die Oberfläche sofort zu befüllen.
Ein Standard-JWT besteht aus drei durch Punkte getrennten Blöcken: dem Header, der die kryptografischen Operationen definiert, dem Payload, der Entitätseigenschaften speichert, und der Signatur, die die Vertrauenswürdigkeit überprüft.
Dekodierte OAuth-Payload-Claims (${count})
JWT-Token links einfügen zum Decodieren.
Dreiteilige JWTs werden nur zur Inspektion dekodiert; lesbare Claims belegen weder Signatur noch Aussteller, Zielgruppe, Schlüssel oder Berechtigung.
Dieser implementierungsspezifische Ablauf für JWT-Decoder entspricht den tatsächlichen Bedienelementen und Grenzen des Browser-Arbeitsbereichs.
Schritt 1
Das vollständige kompakte Token mit beiden Punkten ohne „Bearer “, Anführungszeichen oder fünfteilige JWE-Struktur einfügen.
Schritt 2
Ein Beispiel nur zum Lernen wählen; zum Debuggen das originale Token unverändert lassen – ein Schlüssel ist fürs Dekodieren unnötig.
Schritt 3
Decode JWT starten, damit beide JSON-Abschnitte aus Base64URL und UTF-8 gelesen werden.
Schritt 4
alg, exp/nbf/iat, Issuer, Audience, Subject und eigene Claims prüfen; die Signaturdarstellung ist noch kein Prüfresultat.
Schritt 5
Nur nötige Diagnosewerte kopieren und das unveränderte Token anschließend mit passendem Schlüssel verifizieren.
Folge: Jeder kann eine neue Base64URL-Payload erzeugen; dieser Decoder prüft weder Signatur noch Aussteller/Zielgruppe.
Lösung: Unterstützte HMAC-Tokens verifizieren und serverseitig Algorithmus, Issuer, Audience, Lebensdauer und Berechtigungen erzwingen.
Folge: JWE besitzt fünf Teile und „Bearer …“ enthält Leerzeichen; beides scheitert an der Drei-Segment-/Base64URL-Regel.
Lösung: Scheme-Präfix entfernen und nur ein kompaktes dreiteiliges JWT/JWS mit JSON-Header/Payload verwenden.
Folge: RFC-7519-NumericDate zählt Sekunden seit der Unix-Epoche; Millisekunden ergeben unbrauchbare Fernzeiten.
Lösung: Einheiten des Ausstellers bestätigen und den Rohwert unabhängig mit einem Epoch-Konverter prüfen.
Unverändertes Token zur Claim-Diagnose dekodieren, verschachtelte Struktur untersuchen und unterstützte HMAC-Signaturen anschließend prüfen.
Die ersten beiden Base64URL-Segmente ergeben UTF-8-JSON-Objekte. Der dritte Teil wird nur dargestellt; kein Schlüssel kommt zum Einsatz.
Nein. iss ist bis zur Signaturprüfung und einer vertrauenswürdigen Issuer-Zulassung nur vom Token gelieferter Text.
Eine leere dritte Sektion ist strukturell als Warnfall zugelassen, damit alg=none/Fehler untersucht werden können; vertrauenswürdig wird sie dadurch nicht.
Nein. Kompaktes JWE hat fünf Segmente und verschlüsselte Inhalte; hier sind genau drei Teile mit JSON erforderlich.
Numerische exp/nbf werden in ganzen Unix-Sekunden gegen die Browseruhr verglichen; iat in der Zukunft ist eine Warnung.
Nein. Leerraum, Reihenfolge, Base64URL-Bytes und besonders die Signatur ändern sich; jede Payload-Änderung braucht eine neue Signatur.
Token und dekodierte Claims verbleiben im Browser und werden nicht hochgeladen. Nach Caching arbeitet der Decoder offline; Kopien, Downloads, Screenshots, Erweiterungen und optionale lokale Funktionen unterliegen weiterhin Ihrer Kontrolle.
