JWT-Decoder

JWT online dekodieren

Lesen Sie Header und Payload eines JWT und prüfen Sie exp, iat und nbf als UTC-Zeitpunkte. Auch Bearer-Werte werden erkannt. Die Dekodierung erfolgt im Browser und benötigt keinen Schlüssel.

JWT-DecoderDekodierung im Browser
JWT oder Authorization: Bearer einfügen. Das Tool sendet Tokens nicht an eine Dekodierungs-API und speichert die Eingabe nicht.
Beispiel laden
Nur dekodiert · Signatur nicht geprüft

Lesbare Claims können gefälscht sein. Prüfen Sie die Signatur und die Anforderungen Ihrer Anwendung, bevor Sie dem Token vertrauen.

01 Header

Algorithmus und Metadaten

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

02 Payload

Claims im Token

{
  "sub": "demo-user",
  "iss": "https://example.com",
  "aud": "demo-api",
  "iat": 1704067200,
  "nbf": 1704067200,
  "exp": 1704070800
}

Zeitangaben UTC

Vergleich mit der Gerätezeit, ohne Toleranz für Uhrabweichungen. Daraus folgt keine Aussage über die Gültigkeit des Tokens.

ClaimZeitpunkt in UTCVergleich mit Gerätezeit
iatAusgestellt am2024-01-01T00:00:00.000ZGerätezeit wird gelesen…
nbfVerwendbar ab2024-01-01T00:00:00.000ZGerätezeit wird gelesen…
expAblaufzeit2024-01-01T01:00:00.000ZGerätezeit wird gelesen…

03 Signatur

Angegebener Algorithmus: HS256 · 11 Bytes · ungeprüft

cGxhY2Vob2xkZXI

Was steckt im Token einer fehlgeschlagenen Anfrage?

Ein API-Fehler lässt sich nicht allein am Ablaufdatum erklären. Vergleichen Sie zuerst iss mit dem erwarteten Aussteller und aud mit dem vorgesehenen Empfänger. sub bezeichnet das Subjekt des Tokens. aud kann eine einzelne Zeichenfolge oder eine Liste sein.

Diese Claims sind Angaben aus dem Token, keine bestätigten Tatsachen. Ein Angreifer kann lesbares JSON erzeugen. Welche Claims zwingend vorhanden sein müssen und welche Werte zulässig sind, bestimmt die Anwendung oder das verwendete Protokoll.

Drei Teile, aber nur zwei JSON-Dokumente

Ein übliches signiertes JWT hat die Form header.payload.signature. Header und Payload enthalten Base64url-kodiertes UTF-8-JSON. Der dritte Teil enthält Signatur- oder MAC-Bytes. Er ist kein weiteres JSON-Objekt und wird daher als kodierte Zeichenfolge mit Byteanzahl angezeigt.

Fügen Sie das Token allein oder mit Bearer beziehungsweise Authorization: Bearer ein. Eine vollständige HTTP-Anfrage wird nicht verarbeitet. Die JSON-Ansichten lassen sich einzeln kopieren; große Ganzzahlen und die ursprüngliche Schreibweise von Zahlen bleiben dabei erhalten.

Ablaufzeit: Sekunden statt Millisekunden

exp bezeichnet die Ablaufzeit, nbf den frühesten Nutzungszeitpunkt und iat die Ausstellungszeit. NumericDate zählt Sekunden seit der Unix-Epoche. Der Wert 1704067200 entspricht dem 1. Januar 2024, 00:00 Uhr UTC. JavaScript-Zeitstempel in Millisekunden dürfen nicht unverändert dafür eingesetzt werden.

Die Anzeige vergleicht mit Ihrer Gerätezeit und berücksichtigt keinen Spielraum für abweichende Uhren. Eine noch nicht erreichte Ablaufzeit beweist weder eine korrekte Signatur noch einen passenden Empfänger. Auch eine zukünftige Ausstellungszeit wird lediglich als Hinweis angezeigt.

Dekodieren ist keine Signaturprüfung

Base64url schützt den Inhalt nicht vor dem Lesen. Zum Dekodieren wird deshalb kein Secret benötigt. Eine Anwendung muss dagegen vertrauenswürdige Schlüssel und erlaubte Algorithmen festlegen, die Signatur prüfen und die erforderlichen Claims validieren. Der eingehende alg-Wert allein darf nicht die Vertrauenseinstellungen bestimmen.

Das Tool ruft keine Schlüssel-URLs auf und verwendet keine eingebetteten Schlüssel. Verschlüsselte JWE mit fünf Teilen, verschachtelte JWTs und b64: false werden nicht unterstützt. Die Eingabe ist auf 50.000 Zeichen und 64 JSON-Ebenen begrenzt. Doppelte Schlüssel führen wegen der mehrdeutigen Auslegung zu einem Fehler.

Beispiele zum Ausprobieren

Abgelaufenes Beispiel

Fiktive Claims mit einer Platzhalter-Signatur; kein nutzbarer Zugangsnachweis.

Zurück zum JWT-Decoder

Ohne Signatur

alg: none mit leerem dritten Teil.

Zurück zum JWT-Decoder

Unicode-Claims

Mehrsprachiger Text und mehrere Empfänger; die Signatur ist ein Platzhalter.

Zurück zum JWT-Decoder

Häufige Fragen

Kann ich ein JWT ohne Secret auslesen?

Ja, bei einem dreiteiligen Token mit JSON-Header und JSON-Payload. Dabei wird lediglich Base64url dekodiert. Eine kryptografische Prüfung erfordert passende Schlüssel; diese Funktion bietet das Tool nicht.

Was bedeutet alg: none?

Das Token hat keine kryptografische Signatur. Es besteht weiterhin aus drei Teilen, der letzte ist jedoch leer. Der abschließende Punkt gehört deshalb zum Token. Daraus ergibt sich keine Vertrauenswürdigkeit.

Werden meine Tokens gespeichert?

Das Tool verarbeitet die Eingabe im Browser, sendet sie nicht an eine Dekodierungs-API und legt sie weder dauerhaft noch in der URL ab. Echte Bearertokens können Zugriff gewähren. Zum Ausprobieren stehen fiktive Beispiele bereit.

Sind die Beispiele echte Zugangstokens?

Nein. Das abgelaufene Beispiel hat den exp-Zeitpunkt 1. Januar 2024, 01:00 Uhr UTC, und eine Platzhalter-Signatur. Das Unicode-Beispiel zeigt mehrsprachige Werte und mehrere Empfänger, ebenfalls mit Platzhalter. Das dritte Beispiel ist unsigniert.

Warum wird mein JWT nicht dekodiert?

Prüfen Sie die drei Teile sowie Leerraum, Anführungszeichen und Padding. Header und Payload müssen gültige UTF-8-JSON-Objekte sein. Doppelte Schlüssel, ungültige Kodierung und eine leere Signatur bei alg ungleich none werden abgelehnt. Ein fünfteiliger Wert kann ein verschlüsseltes JWE sein.

RFC 7519 · RFC 7515 · RFC 8725

Zurück zum JWT-Decoder