JWT Decoder: JSON Web Tokens dekodieren, prüfen und erstellen

Token einfügen und Header, Payload und Claims in Klartext sehen, Ablauf prüfen und die Signatur verifizieren. Token, Secret und Schlüssel verlassen Ihr Gerät nicht.

Läuft im Browser: Tokens und Schlüssel verlassen Ihr Gerät nichtKostenlosOhne Anmeldung

Token, Secret und Schlüssel werden nur auf dieser Seite verarbeitet: nicht gesendet, nicht in die URL und nicht in die Analytik übernommen.

Kodiertes Token

Header · Payload · Signatur

Signatur prüfen

Algorithmus: —

Prüfungen

Header

Payload

Claims

Token, Secret und Schlüssel in diesem Browser merken

Sie bauen APIs mit tokenbasierter Authentifizierung?

Wir entwerfen und entwickeln APIs, OAuth-2.0- und OpenID-Connect-Flows und testen sie auf Schwachstellen. Erzählen Sie uns vom Projekt und erhalten Sie eine Schätzung.

Kurz gesagt: JSON Web Token oben einfügen. Der Decoder zeigt Header und Payload als formatiertes JSON, erklärt die Standard-Claims, sagt, ob das Token abgelaufen ist, und prüft die Signatur mit Ihrem Secret oder öffentlichen Schlüssel. Im Tab Encoder entstehen HS256-, HS384- und HS512-Tokens für Tests. Alles läuft im Browser.

Wir haben den JWT Decoder für unsere eigene Arbeit an APIs und Authentifizierung bei YuSMP Group gebaut. Wenn Sie ein Team für tokenbasierte Authentifizierung oder deren Sicherheitsprüfung brauchen: API-Entwicklung und Penetrationstests und Sicherheitsaudits.

Was ist ein JWT?

Ein JSON Web Token (RFC 7519) ist eine kompakte Zeichenkette aus drei Base64URL-Teilen, getrennt durch Punkte: header.payload.signature. Der Header nennt den Signaturalgorithmus (alg) und manchmal die Schlüssel-ID (kid). Der Payload enthält Claims: wer das Token ausgestellt hat, für wen es gilt und wann es abläuft. Die Signatur beweist, dass niemand die ersten beiden Teile verändert hat. Der Payload ist kodiert, nicht verschlüsselt: Jeder mit dem Token kann ihn lesen.

So dekodieren und prüfen Sie ein JWT

Token einfügen in das Feld „Kodiertes Token“. Ein Präfix Bearer und Zeilenumbrüche werden automatisch entfernt. Die drei Teile sind farbig: Header, Payload, Signatur.
Ergebnis lesen. Header und Payload erscheinen als formatiertes JSON. Der Block Claims macht aus exp, iat und nbf Datumsangaben in UTC und Ihrer Zeitzone und zeigt „vor 10 Minuten abgelaufen“ oder „läuft in 3 Stunden ab“.
Warnungen prüfen. Das Tool markiert alg: none, abgelaufene oder noch nicht gültige Tokens, fehlendes exp, Zeiten in Millisekunden und Felder, die nach personenbezogenen Daten aussehen.
Signatur prüfen. Für HS256/384/512 das gemeinsame Secret als Text oder Base64 eingeben. Für RS, PS, ES und EdDSA den öffentlichen Schlüssel als PEM, X.509-Zertifikat, JWK oder ganzes JWKS einfügen oder das JWKS per URL laden: Der passende Schlüssel wird per kid gewählt.

Welche Algorithmen werden unterstützt?

HMAC — HS256, HS384, HS512: gemeinsames Secret (Text oder Base64).
RSA — RS256, RS384, RS512, PS256, PS384, PS512: öffentlicher RSA-Schlüssel: PEM, PKCS#1, Zertifikat, JWK.
ECDSA — ES256, ES384, ES512: öffentlicher EC-Schlüssel P-256, P-384 oder P-521.
EdDSA — Ed25519: öffentlicher Ed25519-Schlüssel, sofern Ihr Browser ihn unterstützt.

Die Prüfung nutzt die im Browser eingebaute WebCrypto-API. Wir haben sie für jeden Algorithmus mit den Beispielen aus RFC 7515, mit Tokens von jwt.io und mit Tokens aus der Python-Bibliothek cryptography abgeglichen.

Häufige Fehler mit JWT

Dem Payload ohne Signaturprüfung vertrauen. Dekodieren ist keine Validierung: Der Server muss bei jeder Anfrage Signatur, exp, iss und aud prüfen.
alg: none akzeptieren oder das Token den Algorithmus wählen lassen. Legen Sie den erwarteten Algorithmus auf dem Server fest.
Ein kurzes HS-Secret. RFC 7518 verlangt einen Schlüssel mindestens so lang wie der Hash: 32 Byte für HS256, 64 für HS512. Kurze Secrets lassen sich offline erraten.
Personenbezogene Daten im Payload. E-Mail, Telefon oder Adresse im JWT kann jeder lesen, der das Token sieht, auch Browser-Erweiterungen und Logs.
Millisekunden in exp. JWT-Zeiten sind in Sekunden. Ein Wert wie 1735689600000 bedeutet das Jahr 56.971, das Token läuft also nie ab.

Häufige Fragen

Ist es sicher, hier ein Produktions-Token einzufügen?

Der Decoder arbeitet vollständig im Browser: Token, Secret und Schlüssel gehen an keinen Server, landen nicht in der URL und nicht in der Analytik. Gespeichert wird nur, wenn Sie „merken“ ankreuzen. Behandeln Sie echte Tokens trotzdem wie Passwörter und nutzen Sie nach Möglichkeit abgelaufene oder Test-Tokens.

Was ist der Unterschied zwischen Dekodieren und Prüfen eines JWT?

Dekodieren liest nur die Base64URL-Teile und zeigt das JSON. Prüfen berechnet die Signatur mit Secret oder öffentlichem Schlüssel neu und beweist, dass Header und Payload nicht verändert wurden. Ein Token kann sich problemlos dekodieren lassen und trotzdem eine ungültige Signatur haben.

Warum steht „Signatur ungültig“, obwohl das Token in meiner App funktioniert?

Meist ist das Secret anders kodiert: Wechseln Sie zwischen Text und Base64. Bei RS- und ES-Tokens prüfen Sie, ob der öffentliche Schlüssel zur kid im Header passt. Das Secret muss Byte für Byte dem des Servers entsprechen, inklusive Zeilenumbrüchen.

Kann ich ein Token über eine JWKS-URL prüfen?

Ja. URL des JWKS einfügen (zum Beispiel /.well-known/jwks.json) und „Schlüssel laden“ drücken. Das ist die einzige Anfrage der Seite, und nur über diesen Button. Erlaubt der Server keine Browser-Anfragen (CORS), öffnen Sie die URL selbst und fügen Sie das JSON ins Schlüsselfeld ein.

Kann ich mit dem Tool ein JWT erstellen?

Ja, im Tab Encoder. Header- und Payload-JSON bearbeiten, HS256, HS384 oder HS512 wählen und ein Secret eingeben. Buttons setzen iat auf jetzt und exp auf eine Stunde später. Das signierte Token lässt sich kopieren oder im Decoder öffnen.

Werden verschlüsselte Tokens (JWE) unterstützt?

Nein. Ein JWE hat fünf Teile und einen verschlüsselten Payload, der ohne privaten Schlüssel nicht lesbar ist. Der Decoder erkennt solche Tokens und weist darauf hin.