Sprache auswählen

JWT Decoder: JSON Web Token entschlüsseln und prüfen

Dekodiere JWT direkt im Browser: Header, Payload und Signatur getrennt anzeigen, Base64URL auflösen und Ablaufzeit der Claims auf einen Blick prüfen.

Mehmet Demiray Veröffentlicht Aktualisiert
Teilen
exp-, iat- und nbf-Claims in lesbare Daten umwandeln

Was ein JWT Decoder leistet

Ein JSON Web Token besteht aus drei Teilen, die durch Punkte getrennt sind: Header, Payload und Signatur. Jeder Teil ist mit Base64URL kodiert, also nicht verschlüsselt, sondern nur in eine kompakte Textform gebracht. Genau hier setzt der Decoder an. Du fügst den vollständigen Token ein, und das Werkzeug trennt die drei Abschnitte automatisch und macht Header und Payload als lesbares JSON sichtbar.

Viele Entwickler kopieren einen Token aus einem Netzwerk-Request oder einem Log und wollen nur schnell sehen, welche Daten darin stecken. Der Decoder zeigt unter anderem:

  • den verwendeten Algorithmus aus dem Header, etwa HS256 oder RS256
  • die Claims im Payload wie sub, iss und aud
  • die Zeitstempel iat, nbf und exp

Weil die Verarbeitung vollständig im Browser stattfindet, verlässt dein Token niemals das Gerät. Das ist wichtig, denn ein JWT enthält oft sensible Sitzungsdaten.

Aufbau eines JSON Web Token

Ein Token folgt immer dem gleichen Muster. Schematisch sieht das so aus:

header.payload.signature

Der Header beschreibt den Token-Typ und das Signaturverfahren. Ein typisches Beispiel im JSON-Format:

`` { "alg": "HS256", "typ": "JWT" } ``

Der Payload trägt die eigentlichen Aussagen, die sogenannten Claims. Hier stehen Angaben zur Identität und zur Gültigkeit:

Claim Bedeutung
sub Subjekt, meist die Nutzer-ID
iss Aussteller des Token
exp Ablaufzeitpunkt als Unix-Zeit
iat Zeitpunkt der Ausstellung

Die Signatur entsteht aus Header und Payload, die mit einem Geheimnis oder einem privaten Schlüssel verarbeitet werden. Sie schützt den Token vor Manipulation. Ein Decoder liest die ersten beiden Teile mühelos, doch die Gültigkeit der Signatur lässt sich ohne den passenden Schlüssel nicht bestätigen. Genau deshalb trennt dieses Werkzeug klar zwischen Lesen und Verifizieren.

Base64URL und der Unterschied zu Base64

JWT nutzt nicht das klassische Base64, sondern die URL-sichere Variante Base64URL. Der Unterschied liegt in wenigen Zeichen. Das Pluszeichen wird zu einem Bindestrich, der Schrägstrich zu einem Unterstrich, und die abschließenden Gleichheitszeichen zur Auffüllung entfallen. Dadurch passt ein Token in eine URL oder einen HTTP-Header, ohne dass Sonderzeichen maskiert werden müssen.

Wer einen JWT-Abschnitt versehentlich in einen reinen Base64-Decoder kopiert, erhält oft Fehler oder unleserliche Zeichen. Dieses Werkzeug behandelt die Kodierung korrekt und ergänzt fehlende Füllzeichen automatisch.

Wenn du allgemeine Zeichenketten umwandeln willst, sind dafür eigene Tools gedacht. Für das Erzeugen einer kodierten Zeichenkette eignet sich Base64 kodieren, und für die Rückumwandlung Base64 dekodieren. Der JWT Decoder kombiniert diese Logik mit dem Wissen über die Struktur eines Token, sodass du dich nicht selbst um die drei Teile kümmern musst.

Claims richtig lesen und die Gültigkeit prüfen

Die spannendsten Felder im Payload sind die Zeitstempel. Sie liegen als Unix-Zeit vor, also als Anzahl der Sekunden seit dem 1. Januar 1970. Der Claim exp legt fest, wann ein Token abläuft, iat markiert die Ausstellung und nbf einen frühesten Gültigkeitsbeginn. Der Decoder rechnet diese Werte in ein lesbares Datum um, damit du sofort erkennst, ob eine Sitzung bereits verfallen ist.

Ein abgelaufener Token wird vom Server zurückgewiesen, auch wenn er technisch noch korrekt kodiert ist. Wenn du also einen Fehler wie eine fehlgeschlagene Authentifizierung untersuchst, lohnt ein Blick auf exp. Liegt der Zeitpunkt in der Vergangenheit, ist die Ursache oft gefunden.

Wichtig bleibt die Trennung zwischen Lesen und Vertrauen. Der Decoder zeigt den Inhalt, prüft aber nicht, ob die Signatur echt ist. Vertraue den Daten erst, nachdem ein Backend die Signatur mit dem geheimen Schlüssel verifiziert hat. Bis dahin sind die Claims nur ein Hinweis, keine Garantie.

Typische Anwendungsfälle im Entwickleralltag

Der Decoder ist vor allem ein Werkzeug zur Fehlersuche. Im Alltag tauchen immer wieder die gleichen Situationen auf, in denen ein schneller Blick in den Token weiterhilft:

  1. Eine API antwortet mit dem Status 401, und du willst wissen, ob die Berechtigungen im Payload fehlen.
  2. Ein Login funktioniert nur sporadisch, und der Verdacht fällt auf einen zu kurzen Ablaufzeitraum.
  3. Ein Drittanbieter sendet einen Token, dessen Felder du erst verstehen musst.

In all diesen Fällen kopierst du den Token aus den Entwicklerwerkzeugen des Browsers oder aus einem Server-Log und liest die Claims direkt aus. Häufig hängt am Payload ein verschachteltes JSON, das schwer zu überblicken ist. Hier hilft der JSON Formatter, um die Struktur sauber einzurücken und Felder leichter zu finden.

So wird aus einer kryptischen Zeichenkette in wenigen Sekunden eine klare Übersicht. Du sparst dir das manuelle Trennen der Abschnitte und das Entschlüsseln der Kodierung von Hand.

Die, die wir am häufigsten beantworten.

Wird mein Token an einen Server gesendet?

Nein. Die gesamte Verarbeitung läuft direkt in deinem Browser. Der Token wird lokal in seine drei Teile zerlegt und dekodiert, ohne dass Daten übertragen werden. So bleiben auch sensible Sitzungsinformationen auf deinem Gerät.

Kann ich mit dem Decoder die Signatur überprüfen?

Der Decoder liest Header und Payload und macht sie lesbar. Die Signatur lässt sich jedoch nur mit dem passenden geheimen Schlüssel oder dem öffentlichen Schlüssel verifizieren, und der liegt nur auf dem Server. Vertraue dem Inhalt eines Token daher erst, nachdem ein Backend die Signatur bestätigt hat.

Ist ein JWT verschlüsselt?

Nein, ein gewöhnlicher JWT ist nur kodiert, nicht verschlüsselt. Header und Payload sind mit Base64URL umgewandelt und für jeden lesbar, der sie dekodiert. Schreibe deshalb niemals Passwörter oder geheime Daten in den Payload.

Warum erkennt der Decoder meinen Token nicht?

Ein gültiger JWT besteht aus genau drei Teilen, die durch Punkte getrennt sind. Fehlt ein Punkt oder wurde beim Kopieren ein Zeichen abgeschnitten, kann der Decoder die Struktur nicht erkennen. Prüfe, ob du den vollständigen Token eingefügt hast und keine Leerzeichen am Anfang oder Ende stehen.

Was bedeutet der Claim exp?

Der Claim exp steht für die Ablaufzeit und wird als Unix-Zeit gespeichert. Liegt dieser Zeitpunkt in der Vergangenheit, gilt der Token als abgelaufen und wird vom Server abgelehnt. Der Decoder rechnet den Wert in ein lesbares Datum um.

Welcher Unterschied besteht zwischen Base64 und Base64URL?

Base64URL ist eine URL-sichere Variante. Das Pluszeichen wird durch einen Bindestrich ersetzt, der Schrägstrich durch einen Unterstrich, und die Füllzeichen am Ende entfallen. Dadurch passt ein Token problemlos in URLs und HTTP-Header.