JWT-Decoder & -Encoder — JSON Web Tokens dekodieren, prüfen und signieren

Dekodiere Header und Payload eines JWT, lies das Ablaufdatum in Klartext, prüfe HS-, RS-, PS- und ES-Signaturen oder signiere ein neues Token. Nichts verlässt deinen Browser.

Token

Header

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

Payload

{
  "sub": "user_42",
  "name": "Ada Lovelace",
  "role": "admin",
  "iat": 1757320000,
  "exp": 1788856000
}

Claims

sub	Subjekt	user_42
name		Ada Lovelace
role		admin
iat	Ausgestellt am	1757320000
exp	Läuft ab	1788856000

Signatur prüfen (HS256)Secret ist Base64-/Base64URL-kodiert

Das Beispieltoken ist mit dem Secret demo-secret-do-not-use signiert.

Beim Dekodieren wird die Signatur nie geprüft: Jeder kann ein JWT lesen, nur die Signatur beweist, wer es ausgestellt hat. HS*-Tokens brauchen das gemeinsame Secret; RS*, PS*, ES* und EdDSA brauchen den Public Key des Ausstellers (PEM, Zertifikat, JWK oder das JWKS aus seinem /.well-known/jwks.json, zugeordnet über kid). Füge keine Produktions-Secrets oder privaten Schlüssel in eine Webseite ein, auch nicht in diese; nutze Testschlüssel.

Tokens und Schlüssel werden in deinem Browser mit WebCrypto verarbeitet und nie gesendet; behandle ein eingefügtes Produktionstoken oder einen Produktionsschlüssel trotzdem wie Zugangsdaten. Alle kostenlosen Tools ansehen.

Ein Problem gefunden oder etwas, das besser sein könnte? Wir lesen jede Nachricht und beheben Fehler schnell.

Dieser kostenlose JWT-Decoder zeigt Header, Payload und Claims eines JSON Web Tokens, macht aus exp, iat und nbf lesbare Daten mit klarer Bewertung gültig oder abgelaufen, prüft die Signatur (HMAC mit einem Secret oder RSA, RSA-PSS, ECDSA und Ed25519 mit Public Key, Zertifikat oder JWK) und hat einen Encoder, der neue Tokens zum Testen signiert. Alles passiert in deinem Browser, und das ist hier wichtiger als bei den meisten Tools: Ein eingefügtes Token ist oft ein aktiver Zugangsnachweis und sollte an keinen Server gesendet werden, auch nicht an unseren.

Ein JWT besteht aus drei Base64URL-Abschnitten, getrennt durch Punkte: einem Header, der den Algorithmus nennt, einer Payload mit Claims und einer Signatur. Die ersten beiden sind nicht verschlüsselt, nur kodiert, und für jeden lesbar; die Signatur beweist, wer das Token ausgestellt hat und dass es nicht verändert wurde. Dekodieren ist daher nicht dasselbe wie Vertrauen, und die Seite hält diesen Unterschied sichtbar.

So funktioniert’s

Füge das Token ein. Ein vorangestelltes „Bearer “ aus einem Authorization-Header ist kein Problem; es wird entfernt.
Lies die Statuszeile: wie lange noch gültig, seit wann abgelaufen oder noch nicht gültig.
Prüfe die Payload und die Claims-Tabelle. Zeit-Claims werden als lokale Daten neben den rohen Unix-Sekunden angezeigt.
Zum Prüfen gibst du den Schlüssel ein und klickst auf Prüfen: das gemeinsame Secret für HS256/384/512 oder bei RS-, PS-, ES- und EdDSA-Tokens den Public Key des Ausstellers als PEM, Zertifikat, JWK oder das ganze JWKS (der Schlüssel wird anhand der kid des Tokens gewählt).
Um ein Token zu erstellen, wechselst du zu Kodieren & signieren, wählst den Algorithmus, bearbeitest das JSON von Header und Payload und gibst ein Secret ein oder fügst einen PKCS#8-Private-Key ein (oder erzeugst ein Testschlüsselpaar). Signiere es und öffne es dann im Decoder, um es zu prüfen.
Kopiere Payload oder Header als formatiertes JSON, wenn du es für einen Bugreport oder eine Testdatei brauchst.

Häufige Fragen

Ist es sicher, hier ein echtes Token einzufügen?

Das Token wird per JavaScript in deinem Browser dekodiert und nie übertragen; du kannst die Internetverbindung trennen, und die Seite funktioniert weiter. Behandle ein Produktivtoken trotzdem wie ein Passwort: Füge es in keine Seite ein, der du nicht vertraust, und nimm nach Möglichkeit ein kurzlebiges Testtoken.

Warum kann ich die Payload ohne das Secret lesen?

Weil JWTs signiert, nicht verschlüsselt sind. Die Payload ist Base64URL-kodiertes JSON, das jeder dekodieren kann. Das Secret (oder der Private Key) wird nur gebraucht, um die Signatur zu erstellen oder zu prüfen. Leg niemals sensible Daten in eine JWT-Payload, es sei denn, du verwendest JWE, die verschlüsselte Variante, die dieses Tool nicht dekodiert.

Was bedeuten exp, iat und nbf?

Es sind Unix-Zeitstempel in Sekunden. exp ist der Ablaufzeitpunkt des Tokens; iat der Ausstellungszeitpunkt; nbf (not before) der früheste Zeitpunkt, ab dem es gültig ist. Ein Prüfer muss ein Token nach exp oder vor nbf ablehnen. Die Statuszeile hier wendet beide Regeln auf die aktuelle Zeit an.

Wie prüfe ich ein RS256- oder ES256-Token?

Du brauchst den Public Key des Ausstellers, nie den privaten. Identitätsanbieter veröffentlichen ihn als JWKS unter einer URL wie https://issuer/.well-known/jwks.json (Auth0, Okta, Cognito, Azure AD und Google tun das alle). Füge das ganze JWKS ein, dann wird der Schlüssel verwendet, dessen kid zum Token-Header passt, oder füge einen einzelnen JWK, einen PEM-Public-Key (BEGIN PUBLIC KEY) oder ein X.509-Zertifikat ein. Die Seite ruft selbst nichts ab, kopiere das JWKS also aus deinem Browser.

Kann ich hier ein JWT erstellen und signieren?

Ja. Kodieren & signieren nimmt JSON für Header und Payload und signiert mit HS256/384/512 und einem Secret oder mit RS, PS, ES oder EdDSA und einem Private Key im PKCS#8-PEM-Format (BEGIN PRIVATE KEY). Ältere Dateien mit BEGIN RSA PRIVATE KEY sind PKCS#1; wandle sie mit openssl pkcs8 -topk8 -nocrypt -in key.pem um. Verwende nur Testschlüssel: Ein produktiver Signaturschlüssel, der in irgendeine Webseite eingefügt wurde, gilt als kompromittiert.

Was bedeutet „alg: none“, und warum die Warnung?

Es erklärt, dass das Token keine Signatur hat. Manche Bibliotheken haben solche Tokens früher als gültig akzeptiert, wodurch Angreifer jede beliebige Payload fälschen konnten. Ein richtig konfigurierter Prüfer lehnt alg none sofort ab. Wenn du es in einem echten System siehst, ist das ein Sicherheitsbefund, keine Kuriosität.

Aufbau eines JWT

Header: {"alg":"HS256","typ":"JWT"} sagt dem Prüfer, mit welchem Algorithmus das Token signiert wurde. Payload: die Claims, ein JSON-Objekt mit allem, was der Aussteller aufnehmen wollte, plus die registrierten Claims (iss, sub, aud, exp, nbf, iat, jti), die Prüfer verstehen. Signatur: HMAC oder eine digitale Signatur über base64url(header).base64url(payload). Ändere ein Zeichen der Payload, und die Signatur passt nicht mehr – genau darum geht es.

Häufige JWT-Fehler

• Der Payload vertrauen, ohne die Signatur zu prüfen, oder mit dem im Token genannten Algorithmus prüfen statt mit dem, den der Server erwartet (Algorithm Confusion).

• Langlebige Access Tokens. Halte exp kurz (Minuten bis eine Stunde) und nutze für längere Sitzungen ein Refresh Token.

• Persönliche oder geheime Daten in die Payload legen; jeder, der das Token besitzt, kann sie lesen.

• Tokens im localStorage einer Website speichern, die irgendeine XSS-Angriffsfläche hat. Ein httpOnly-Cookie ist für Browsersitzungen sicherer.

• Vergessen, aud und iss zu prüfen – dadurch lässt sich ein Token, das für einen Dienst ausgestellt wurde, gegen einen anderen wiederverwenden.

• HMAC-Secrets, die zu kurz oder von Menschen gewählt sind. HS256 braucht mindestens 256 Bit (32 zufällige Bytes); ein erratbares Secret lässt sich offline aus einem einzigen Token per Brute Force knacken.

Welchen Signaturalgorithmus du wählen solltest

• HS256 (HMAC-SHA256): Ein gemeinsames Secret signiert und prüft. Einfach und schnell, aber jeder Dienst, der prüft, kann auch Tokens ausstellen. In Ordnung innerhalb eines Backends.

• RS256 (RSA PKCS#1 v1.5 mit SHA-256): die am breitesten unterstützte asymmetrische Option; der Aussteller behält den Private Key, alle anderen prüfen mit dem Public Key. Signaturen sind bei einem 2048-Bit-Schlüssel 256 Byte groß.

• PS256 (RSA-PSS): dieselben Schlüssel wie RS256 mit einem moderneren Padding-Verfahren; nutze es, wenn alle Abnehmer es unterstützen.

• ES256 (ECDSA P-256): viel kleinere Schlüssel und 64-Byte-Signaturen bei vergleichbarer Sicherheit; verbreitet in neueren Systemen und von manchen vorgeschrieben (Apple, APIs im Umfeld von WebAuthn).

• EdDSA (Ed25519): schnelle, deterministische Signaturen, zunehmend von Bibliotheken unterstützt; die Browser-Unterstützung kam später als bei den anderen.