JWT-Tokens dekodieren und inspizieren

Ein JSON Web Token (JWT) ist die Zeichenkette, die dein Browser sendet, um nach dem Login zu beweisen, wer du bist — und es ist von jedem lesbar, der es besitzt. Das ist kein Fehler im Design; es ist das Design. Das eigentliche Risiko ist nicht, ein Token zu lesen, sondern wo du es liest. Ein live Token in eine beliebige Decoder-Seite einzufügen, übergibt deine Sitzung an einen Server, den du nicht kontrollierst. Der JWT Decoder lädt nichts hoch — er dekodiert Header, Payload und Claims vollständig im Browser und sagt es dir vorab: der Sicherheitshinweis unter der Eingabe lautet “Wird lokal im Browser decodiert. Die Signatur wird nicht verifiziert.”

TL;DR

Ein JWT ist kein versiegelter Umschlag. Es sind drei Base64URL-Teile mit einer Signatur am Ende, und die ersten beiden sind getarnter Klartext.

Ein JWT hat drei Teile — header.payload.signature, jeweils durch einen Punkt getrennt. Die ersten beiden sind Base64URL-kodiertes JSON.
Jeder, der das Token hat, kann es lesen — Header und Payload dekodieren sich in Millisekunden, ohne Schlüssel.
Die Signatur beweist Integrität, keine Vertraulichkeit — sie erlaubt dem Server zu bestätigen, dass das Token nicht verändert wurde. Sie verbirgt nicht den Inhalt.

Dekodiere lokal, lies, was das Token sagt, und behandle den Payload nie als sicheren Ort für Geheimnisse.

Aufbau eines JWT

Jedes JWT hat genau drei Base64URL-Segmente, durch Punkte verbunden:

<header>.<payload>.<signature>

Nimm das Beispiel-Token des Werkzeugs (lade es mit der Schaltfläche Beispiel) und betrachte die ersten beiden Segmente. Sie sehen wie Rauschen aus, aber jedes ist nur Base64URL-kodiertes JSON. Dekodiert lesen sie:

Header — {"alg":"HS256","typ":"JWT","kid":"example-demo"}. Deklariert den Algorithmus, den Token-Typ und die Key-ID. Es sagt dem Server wie zu verifizieren, nichts Geheimes.
Payload — {"iss":"example-app","sub":"demo-user","name":"홍길동","scope":"read write","iat":1704067200,"nbf":1704067200,"exp":4102444800}. Das sind die Claims: Aussagen über das Token — wer es ausgestellt hat, für wen es ist, was es erlaubt und wann es abläuft.
Signature — demo-signature. In einem echten Token ist dies ein kryptografischer Wert, den der Server über Header und Payload mit einem Secret oder privaten Schlüssel berechnet. Das Beispiel liefert bewusst einen Platzhalter.

Header und Payload sind die lesbaren Teile. Die Signatur ist das einzige Stück, das du nicht wieder in seine Eingabe zurückverwandeln kannst — und sie existiert, um zu beweisen, dass die anderen beiden auf dem Weg nicht geändert wurden, nicht um sie privat zu halten. (Für die Kodierungs-Hälfte dieser Geschichte siehe Base64-Kodierung vs. Verschlüsselung — ein JWT ist ein praktisches Beispiel für “Base64 ist kein Geheimnis”.)

Standard-Claims dekodiert

Der Payload ist eine Sammlung von Claims — per Konvention vereinbarte Schlüssel/Wert-Paare. Die registrierten, denen du fast immer begegnest:

iss (Aussteller) — wer das Token ausgestellt hat, meist eine URL oder Kennung.
sub (Betreff) — worum es im Token geht, typischerweise eine Benutzer- oder Konto-ID.
aud (Audience) — für wen das Token bestimmt ist. Ein Token für den Abrechnungsdienst sollte vom Profildienst abgelehnt werden.
exp (Ablauf) — der Zeitpunkt, zu dem das Token ungültig wird, als Unix-Zeitstempel. Das ist der wichtigste Claim zum Prüfen.
iat (ausgestellt am) — wann das Token erzeugt wurde.
nbf (nicht vor) — der früheste Zeitpunkt, zu dem das Token gültig ist. Zusammen mit iat ermöglicht es Ausstellern, leicht vordatierte Token auszustellen.

exp ist wichtig, weil Tokens Inhaber-Anmeldedaten sind: Wer ein gültiges vorzeigt, kommt rein. Kurze, ablaufende Tokens begrenzen den Schaden, wenn eines gestohlen wird. Ein Token mit weit in der Zukunft liegendem exp ist ein langlebiger Schlüssel; ein Token ohne exp ist faktisch dauerhaft. Lies immer den Ablauf, bevor du vertraust, was ein Token behauptet.

Schritt für Schritt: ein Token dekodieren

Der JWT Decoder läuft vollständig im Browser — das Token verlässt nie dein Gerät. Der Ablauf:

Token einfügen. Lege eine vollständige header.payload.signature-Zeichenkette in das Feld JWT-Token-Eingabe. Klicke Beispiel, um stattdessen das eingebaute Demo-Token zu laden.
Dekodieren. Klicke Decodieren. Das rechte Panel füllt sich mit dem geparsten Ergebnis. (Wenn du die Eingabe danach bearbeitest, lautet die Statuszeile “Die Eingabe wurde geaendert. Decodiere erneut zum Aktualisieren.”, damit du nie einen veralteten Parse liest.)
Lies das Diagnose-Panel. Oben führt es Algorithm, Type und Key ID aus dem Header auf, plus die Byte-Größe jedes Segments. Hier treten fehlerhafte oder leere Signatur-Tokens zutage — eine Warnung lautet “Token ist abgelaufen.”, “Token ist noch nicht gueltig.” oder “Signatursegment ist leer. Decodieren verifiziert keine Signaturen.”
Prüfe die Claims-Zeitleiste. Die Tabelle legt die zeitbasierten Claims — exp, iat, nbf — mit rohen Sekunden, der ISO UTC-Lesart und einem Status von Aktiv, Vergangen oder Zukunft aus. Eine exp-Zeile mit Vergangen ist ein abgelaufenes Token; eine nbf-Zeile mit Zukunft heißt, es ist noch nicht gültig.
Lies die Header- und Payload-Panels. Jedes ist formatiertes JSON mit einer Kopieren-Schaltfläche. Das ist der volle, dekodierte Inhalt des Tokens — Aussteller, Betreff, Scopes, alles.
Kopiere, was du brauchst. Nutze Kopieren auf einem Panel oder Alles kopieren für eine Textzusammenfassung von Header, Payload und Signatur zusammen. Nutze Leeren, um alles zu löschen.

Das Ganze ist eine Leseoperation. Das Werkzeug ruft nicht nach außen, verifiziert die Signatur nicht gegen einen Aussteller und speichert das Token nicht — Seite neuladen und es ist weg.

Der kritische Irrtum

Weil ein JWT zur Authentifizierung verwendet wird, nehmen Leute an, sein Inhalt sei geheim. Ist er aber nicht. Header und Payload sind Base64URL-kodiert, was Kodierung ist, keine Verschlüsselung — von jedem in einem Schritt umkehrbar, ohne Schlüssel. (Das ist dieselbe Falle wie Base64 als Sicherheit zu behandeln; siehe Base64-Kodierung vs. Verschlüsselung.)

Das hat eine eiserne Regel: lege niemals ein Geheimnis in den Payload eines JWT. Keine Passwörter, keine API-Schlüssel, keine Kreditkartennummern, keinerlei Anmeldedaten. Wenn es im Payload steht, nimm an, dass es öffentlich ist — denn sobald das Token den Server verlässt, kann es jeder auf dem Pfad lesen. Die Signatur garantiert, dass das Token nicht verändert wurde; sie garantiert nichts darüber, wer es sehen kann.

Wenn du ein Token dekodierst und der Payload sauber lesbar ist, bedeutet das, dass das Format ehrlich ist — nicht dass der Inhalt privat ist. Entwickle entsprechend: lege nur in den Payload, was der Client braucht, behalte echte Geheimnisse serverseitig und überlasse kurzen exp-Werten den Schutz.

Häufige Fragen

Ist es sicher, ein JWT zu dekodieren?

Ja — ein JWT zu dekodieren ist nur das Base64URL-Dekodieren zweier JSON-Segmente. Es offenbart, was das Token ohnehin im Klartext jedem sagt, der es besitzt; es schwächt, offenbart oder invalidiert das Token nicht. Unsicher ist, wo du dekodierst: ein Live-Token in eine unbekannte Website einzufügen, kann deine Sitzung verraten. Dekodiere im Browser mit dem JWT Decoder und das Token verlässt nie dein Gerät.

Kann das Werkzeug mein Token lesen?

Nein. Der JWT Decoder läuft vollständig clientseitig. Das Token wird im Speicher deines Browsers geparst; nichts wird hochgeladen, protokolliert oder auf einem Server gespeichert. Der Sicherheitshinweis unter der Eingabe sagt es direkt: “Wird lokal im Browser decodiert.” Seite neuladen und die Eingabe ist gelöscht.

Was bedeutet hier “abgelaufen”?

Es bedeutet, dass der exp-Claim des Tokens — sein Ablaufzeitstempel — in der Vergangenheit liegt, sodass ein verifizierender Server ihn ablehnen sollte. Im Werkzeug zeigt ein abgelaufenes Token exp als Vergangen in der Claims-Zeitleiste und löst eine “Token ist abgelaufen.”-Warnung im Diagnose-Panel aus. “Abgelaufen” handelt von Gültigkeit, nicht von Lesbarkeit: das Token dekodiert weiterhin einwandfrei, ihm sollte nur nicht vertraut werden.

Wo wird das Token validiert?

Nicht in diesem Werkzeug. Der JWT Decoder dekodiert — er liest Header und Payload und zeigt die Claims-Zeitleiste. Er verifiziert die Signatur nicht gegen den Schlüssel eines Ausstellers, kann also nicht sagen, ob ein Token echt ist, sondern nur, was es behauptet. Echte Validierung (Signatur, exp, aud und Aussteller prüfen) passiert auf dem Server, der das Token ausgestellt hat oder ihm vertraut. Deshalb ist der Sicherheitshinweis explizit: “Die Signatur wird nicht verifiziert.”

JWT-Tokens sicher dekodieren und inspizieren