JWT Decoder & Debugger: Token online dekodieren und prüfen

Ja. Der JWT Decoder & Debugger läuft direkt auf dieser Seite in deinem Browser, ohne Konto, ohne Anmeldung und ohne Installation.

Nein. Dekodieren, Signieren und die Signaturprüfung laufen ausschließlich in deinem Browser, die Kryptografie über die Web Crypto API. Token, Secret und öffentlicher Schlüssel werden nicht hochgeladen. Echte JWTs enthalten trotzdem oft Session- oder API-Zugangsdaten, zum Testen sind Test-Tokens die bessere Wahl.

Ja. Ein JWT ist nicht verschlüsselt: Header und Payload sind nur Base64URL-kodiert und für jeden lesbar. Das Secret oder der öffentliche Schlüssel wird nur für die Signaturprüfung gebraucht und, bei HS256, HS384 und HS512, zum Neu-Signieren. Dekodieren beweist also nicht, dass ein Token echt ist, das zeigt erst die Signaturprüfung.

Bei HS256, HS384 und HS512 gibst du das Secret ein. Steht im Header RS256, RS384, RS512, PS256, PS384, PS512, ES256, ES384 oder ES512, erscheint stattdessen ein Feld für den öffentlichen Schlüssel im PEM-Format „BEGIN PUBLIC KEY“ (SPKI). RSA PUBLIC KEY (PKCS#1) und Zertifikate nimmt das Tool nicht an. Das Ergebnis steht oben als „Gültig“ oder „Ungültig“, ohne Secret oder Schlüssel als „Nicht geprüft“. Andere Algorithmen prüft das Tool nicht.

Enthält die Payload exp, iat oder nbf als Zahl, zeigt das Tool diese Claims über der Payload als Datum in UTC an. Bei exp steht dazu, in wie viel Zeit der Token abläuft oder seit wann er abgelaufen ist, ein abgelaufenes exp wird rot markiert. Liegt nbf in der Zukunft, siehst du, ab wann der Token gültig ist.

Ja. Bearbeite Header oder Payload direkt, etwa exp, Rollen oder eigene Claims, oder wähle einen anderen Algorithmus. Sobald du etwas änderst, entsteht im Feld „Encoded (JWT)“ live ein neuer, mit deinem Secret signierter Token. Signieren funktioniert nur mit HS256, HS384 und HS512: RS-, PS- und ES-Algorithmen bräuchten dafür einen privaten Schlüssel, den das Tool nicht verwendet.

Kopiere nur den Teil nach „Bearer “ und füge ihn ein. Das Präfix wird nicht automatisch entfernt, und ein JWT muss aus genau drei durch Punkte getrennten Teilen bestehen (Header.Payload.Signatur). Mit Präfix kann der Header nicht gelesen werden und das Tool zeigt eine Fehlermeldung.

Ein JWT besteht aus drei Base64URL-kodierten Teilen, getrennt durch Punkte: Header (z. B. alg und typ), Payload mit den Claims und Signatur. Das vorausgefüllte Beispiel zeigt den Aufbau: ein HS256-Token mit sub, name und iat, der mit dem Beispiel-Secret als „Gültig“ geprüft wird.