So dekodieren Sie ein JWT

Fügen Sie den Token in einen Decoder ein, der in Ihrem Browser läuft, niemals in einen, der einen Upload verlangt; lesen Sie Header und Payload, prüfen Sie exp gegen die aktuelle Zeit und behandeln Sie alg:none als Alarm. Dekodieren ist Lesen, nicht Verifizieren – nur der Schlüssel des Ausstellers beweist, dass ein Token echt ist. Jeder der folgenden Schritte läuft lokal auf dem JWT-Decoder dieser Website.

Nur lokal

Direkt zum Tool? JWT dekodieren öffnenJSON Web Token dekodieren und jeden Claim verstehenTool öffnen

Ein JSON Web Token sieht aus wie Tapete – drei Base64-Segmente, verbunden durch Punkte – und genau diese Tarnung ist der Grund, warum sein gezieltes Dekodieren ein Verfahren wert ist, statt auf ihn zu schielen. Innen steckt ein Header, der den Signaturalgorithmus nennt, ein Payload, der nennt, wem der Token gehört und wann er abläuft, und eine Signatur, die (wenn sie echt ist) beides an den Aussteller bindet. Die ersten beiden kann jeder lesen; den dritten kann nur prüfen, wer den Schlüssel hat.

Diese Seite ist die sichere Variante dieses Leseauftrags: fünf Schritte, jeder mit einer Kontrolle, alle ausgeführt in Ihrem eigenen Browser. Der Unterschied zählt, denn ein JWT ist ein Bearer-Credential – wer es in der Hand hat, kann es benutzen. Einen Live-Token in irgendeine Webseite einzufügen, die ihn serverseitig dekodiert, heißt, dieses Credential an den Betreiber der Seite zu übergeben; in ein Tool, das lokal dekodiert, übergeben Sie ihn niemandem – und das Netzwerk-Panel ist der Weg, diese Behauptung zu prüfen, statt ihr zu vertrauen.

Eine Erwartung gleich vor dem ersten Schritt: Ein Decoder kann Ihnen sagen, was ein Token behauptet, und markieren, was falsch aussieht, aber er kann nicht bezeugen, dass ein Token echt ist. Echtheit ist eine Signaturfrage, und Signaturfragen brauchen den Schlüssel des Ausstellers. Der letzte Schritt handelt davon, wo diese Verifizierung tatsächlich passiert – und warum die Antwort meistens nicht diese Seite ist.

Alle fünf Schritte laufen im JWT-Decoder der Website – einfügen, lesen, und jeder Claim kommt samt seiner Bedeutung an.

Für die volle Anatomie der drei Segmente erklärt der Leitfaden zur JWT-Struktur jeden Teil mit echten Beispielen, bevor Sie einen Live-Token inspizieren.

Die Schritte

Kopieren Sie nur den Token – nichts davor und nichts danach
Kopieren Sie aus dem Response-Header, dem localStorage-Eintrag oder der Anfrage, die Sie inspizieren, genau die drei Base64-Segmente: das Stück, das mit eyJ beginnt und am letzten Zeichen des dritten punktgetrennten Segments endet. Entfernen Sie ein Bearer-Präfix, Anführungszeichen und Leerraum – ein Decoder verträgt etwas davon, aber ein sauber eingefügter Token macht jede nachgelagerte Prüfung eindeutig.
Prüfen: Was Sie kopiert haben, beginnt mit eyJ (das Base64 von {" – jeder JWT-Header tut das) und enthält keine Leerzeichen. Diese winzige Prüfung findet den häufigsten Einfüge-Fehler, bevor irgendein Tool im Spiel ist.
Fügen Sie ihn in einen Decoder ein, der lokal läuft
Öffnen Sie den JWT-Decoder und fügen Sie ein. Header und Payload dekodieren sich sofort, im Tab – kein Upload, und das Netzwerk-Panel zeigt keine Anfrage, die den Token trägt. Das ist der Schritt, an dem sich die sichere und die unsichere Variante dieses Verfahrens scheiden: Ein serverseitiger Decoder hat Ihren Token gesehen; ein lokaler nicht, denn er verlässt Ihren Rechner nie.
Prüfen: Zwei JSON-Objekte erscheinen – zuerst der Header, darunter der Payload – ohne Fehlermeldung dazwischen. Meldet der Decoder ungültiges Base64 oder kaputtes JSON, wurde der Token beim Kopieren abgeschnitten oder verhunzt; kopieren Sie ihn erneut aus der Quelle.
Lesen Sie den Header – der Algorithmus setzt das Bedrohungsmodell
Das alg im Header nennt, wie der Token signiert wurde: HS256 bedeutet ein gemeinsames Geheimnis, RS256 oder ES256 bedeutet ein Schlüsselpaar, dessen private Hälfte nur der Aussteller hält, none bedeutet unsigniert. Das Tool markiert alg:none lautstark, denn ein unsignierter Token ist eine Behauptung, die jeder hätte schreiben können – ihn zu akzeptieren ist kein Fehler, es ist ein Policy-Versagen. Notieren Sie sich das alg jetzt; Schritt fünf braucht es.
Prüfen: Die alg-Zeile zeigt einen echten Algorithmus (HS256, RS256, ES256 sind die gängigen drei) und niemals none. Zeigt sie doch none, halten Sie inne: Der Token beweist nichts über sich selbst, und wer ihn ausgestellt hat, muss davon hören.
Lesen Sie den Payload – und prüfen Sie exp gegen die echte Zeit
Die Claims des Payloads sind die ganze Geschichte des Tokens: sub nennt, wem er gehört, iss nennt, wer ihn gemacht hat, aud nennt, wer ihn annehmen darf, und exp ist der Moment seines Ablaufs – vom Tool in ein echtes Datum mit Uhrzeit dekodiert, nicht die 1735689600, die Sie selbst umrechnen müssten. Das Tool erhebt zudem Hinweise: ein abgelaufener Token, einer ganz ohne exp, einer, dessen nbf in der Zukunft liegt, weil die Uhr des Ausstellers vorgeht.
Prüfen: Die exp-Zeile zeigt ein Datum, mit dem Sie rechnen können – „vor 4 Stunden abgelaufen“ oder „läuft in 11 Minuten ab“ – und die Hinweisliste passt zu dem, was Sie sehen. Ein Token ohne exp verdient Misstrauen: Auf dem Papier läuft er nie ab.
Verifizieren Sie beim Aussteller – nicht beim Decoder
Dekodieren beweist nichts über Echtheit: Das Signatursegment ist nur gegen einen Schlüssel prüfbar, und der Schlüssel gehört dem Aussteller. In der Praxis passiert die Verifizierung dort, wo der Schlüssel lebt – in Ihrem Backend, in einem API-Gateway, in der Bibliothek Ihres Identitätsanbieters –, nicht in einem Browser-Tab. Debuggen Sie, warum ein Dienst einen Token abgelehnt hat, bringen Sie die dekodierten Claims zu diesem Dienst: ein bereits vergangenes exp, ein nicht passendes aud oder ein kid, das der Schlüssel-Cache noch nicht übernommen hat, erklären die meisten Ablehnungen.
Prüfen: Sie können für den Token vor Ihnen benennen, wer ihn verifizieren muss (der Dienst, der ihn angenommen hat) und was dieser Dienst prüft (die Signatur gegen den Schlüssel des Ausstellers, dazu exp, nbf und aud). Wenn nicht, hat der Leitfaden zur JWT-Struktur das fehlende Teil.

Dekodieren und Verifizieren sind verschiedene Verben

Dekodieren ist Base64 und JSON-Parsing – Lesen. Verifizieren ist eine kryptografische Operation – die Signatur gegen einen Schlüssel prüfen, den nur der Aussteller besitzt. Ein Decoder, der Ihnen ein grünes „gültig“-Abzeichen zeigen würde, läge, denn er kann den privaten Schlüssel des Ausstellers nie haben, und selbst bei Public-Key-Algorithmen gehört die Prüfung zum akzeptierenden Dienst, der weiß, welcher Schlüssel und welche Audience gelten.

Deshalb behauptet das Tool nie Gültigkeit, sondern erklärt, was es sieht: den Algorithmus, die Claims, den Ablaufzeitpunkt als Datum und die Hinweise, die ein aufmerksamer Leser erheben würde. Der Leser, der ein Urteil braucht – die API, die den Token empfängt –, ist die einzige Partei mit dem Material dafür.

Die Claims, die sich jedes Mal zu lesen lohnen

Vier registrierte Claims tragen den größten Teil der Geschichte. exp: wann der Token abläuft – die mit Abstand nützlichste Zeile der Seite. sub: von wem der Token handelt, meist eine Nutzer- oder Dienst-Kennung. iss und aud: wer ihn ausgestellt hat und wer ihn annehmen darf – ein Token für eine API wird von einer anderen oft abgelehnt, und die ablehnende Seite funktioniert nicht falsch, sie liest aud korrekt.

Eigene Claims (Rollen, Scopes, Tenant-IDs) stehen daneben und werden genauso dekodiert, aber behandeln Sie sie als Behauptungen, nicht als Fakten: Sie sind nur so vertrauenswürdig wie die Signatur hinter ihnen, die der Decoder nicht geprüft hat. iat (issued at) und nbf (not before) vervollständigen die Zeitachsen-Claims und erklären die Fehlerklasse „token not yet valid“, die fast immer auf Uhrversatz zurückgeht.

Was ein Decoder markieren kann – und was nur der Server wissen kann

Die Hinweis-Ebene findet, was der Payload von sich aus preisgibt: alg:none, ein leeres Signatursegment, ein exp in der Vergangenheit, einen Token ganz ohne exp, ein nbf in der Zukunft. Das sind die Defekte, die ohne jeden Schlüssel sichtbar sind, und es lohnt sich, sie zu lesen, selbst wenn der Token „funktioniert“ – ein System, das einen abgelaufenen Token akzeptiert, ist ein System, über das Sie Bescheid wissen wollen.

Was kein Browser-Tool Ihnen sagen kann: ob die Signatur tatsächlich verifiziert, ob der Aussteller diese Sitzung noch anerkennt, ob der Token widerrufen wurde. Diese Antworten liegen hinter dem Schlüssel des Ausstellers und seinen Aufzeichnungen. Die Ehrlichkeit des Decoders ist die Grenze, die er zwischen dem Lesen eines Tokens und dem Vertrauen in einen zieht.

Wo sich Token verstecken – und warum das für lokales Dekodieren spricht

JWTs sitzen in Authorization-Headern, im localStorage des Browsers, in URL-Fragmenten nach Login-Weiterleitungen und in Anwendungs-Logs – Orte, die viel beiläufiger kopiert werden als Dateien. Jede dieser Kopien ist bis zum Ablauf ein lebendes Credential, und deshalb besteht der Dekodier-Schritt dieses Verfahrens auf einem lokalen Tool: Screenshots, Tickets und Chat-Nachrichten mit dekodierten Payloads kann jeder lesen, aber der rohe Token selbst sollte nirgendwohin reisen außer zu den Diensten, die ihn verifizieren sollen.

Die praktischen Gewohnheiten folgen daraus: lokal dekodieren, vor dem Teilen schwärzen (der Payload in einem Screenshot reicht meist zum Debuggen), und wenn ein Token zum Debuggen weitergegeben werden muss, dann über den Kanal, den der Aussteller für akzeptabel halten würde – nicht über eine öffentliche Paste-Site.

Häufig gestellte Fragen

Ist es sicher, mein JWT in diesen Decoder einzufügen?

Ja, denn die Dekodierung passiert in Ihrem Browser – der Token wird von lokalem Code geparst und nie irgendwohin übertragen. Das müssen Sie nicht auf Treu und Glauben nehmen: Öffnen Sie die DevTools, öffnen Sie das Netzwerk-Panel, fügen Sie einen Token ein und beobachten Sie, dass keine Anfrage ihn trägt. Die Content-Security-Policy der Website verbietet ausgehende Verbindungen von Grund auf, sodass nicht einmal ein Bug ihn abgreifen könnte.

Kann mir Dekodieren sagen, ob ein Token gültig ist?

Nein, und ein Decoder, der das behauptet, führt Sie in die Irre. Gültigkeit ist eine Signaturfrage – der Token muss gegen den Schlüssel des Ausstellers geprüft werden, dazu gegen die exp-, nbf- und aud-Richtlinien des Dienstes, der ihn empfängt. Ein Decoder zeigt Ihnen, was der Token sagt, und markiert Oberflächendefekte (abgelaufen, unsigniert, fehlendes exp); das Urteil fällt der Verifizierer, der den Schlüssel hält.

Was bedeutet alg:none und warum ist es gefährlich?

Es bedeutet, dass der Header keinen Signaturalgorithmus deklariert – das Signatursegment sollte leer sein, und der Inhalt des Tokens ist eine Behauptung, die jeder hätte schreiben können. Algorithmen wie HS256 existieren gerade dafür, dass Manipulation auffällt; alg:none nimmt diese Garantie. Ein Decoder markiert es lautstark, weil das Akzeptieren eines solchen Tokens eine bekannte Schwachstellenklasse ist, keine Format-Marotte.

Warum zeigt mein Token als abgelaufen, obwohl die App noch funktioniert?

Weil die App ihn erneuert hat. Kurzlebige Access-Tokens laufen absichtlich ab und werden im Hintergrund gegen neue eingetauscht, meist mit einem Refresh-Token; was Sie kopiert haben, war vermutlich schon eine ausgediente Generation. Dekodieren Sie den Token, den die App gerade sendet – sein exp sollte in der Zukunft liegen; ist er es nicht, prüft der Dienst, der ihn annimmt, den Ablauf nicht, und das ist gut zu wissen.

Womit werden exp, iat und nbf gemessen?

Sekunden seit dem 1. Januar 1970 UTC – Unixzeit –, weshalb ein roher Payload sie als zehnstellige Zahlen wie 1735689600 zeigt. Der Decoder wandelt jeden in ein echtes Datum mit Uhrzeit um und drückt das Verhältnis zum Jetzt aus („vor 4 Stunden abgelaufen“, „läuft in 11 Minuten ab“) – die Form, mit der ein Mensch tatsächlich etwas anfangen kann.

Kann ich einen Screenshot eines dekodierten Tokens teilen?

Der dekodierte Header und Payload sind meist unbedenklich – sie sind von Design wegen lesbar, und ein Screenshot mit Claims ist der übliche Weg zu debuggen. Nie geteilt werden darf der rohe Token selbst: Er ist ein Bearer-Credential, und wer ihn hält, kann ihn bis zum Ablauf benutzen. Schwärzen Sie Signatursegmente und jede Kennung, die Sie nicht in ein Ticket schreiben würden, und lassen Sie den vollständigen Token gar nicht erst in Screenshots.

ToolsByUs-Team · Wie wir unsere Tools prüfen