JWT-Decoder

JSON Web Tokens dekodieren und Header, Payload und Signatur prüfen

JWT-Token

Jump to the next useful tool without leaving your flow.

See more

Über dieses Tool

Ein JWT sind drei Base64url-encodierte Segmente, verbunden durch Punkte: ein Header, der sagt, welcher Algorithmus ihn signiert hat, ein Payload mit den Claims und eine Signatur. Die Eigenschaft, die Leute am meisten überrascht: Das Payload ist nicht verschlüsselt. Es ist nur encodiert, das heißt, wer das Token hält, kann jeden Claim darin ohne Key, Passwort oder dieses Tool lesen – Decodieren ist eine Zwei-Zeilen-Operation in jeder Sprache. Das ist Absicht: JWTs sollen vom Client lesbar und vom Server verifizierbar sein. Was die Signatur schützt, ist Integrität, nicht Geheimhaltung. Ändere ein einzelnes Zeichen des Payloads und die Signatur matcht nicht mehr, der Server lehnt es ab. Diese Unterscheidung hat eine praktische Folge, die klar gesagt werden sollte: Lege nie etwas Vertrauliches in ein JWT-Payload, weil es für jeden, der das Token hält, praktisch öffentlich ist. Decodieren hier passiert vollständig in deinem Browser.

So verwendest du dieses Tool

  1. Füge das Token einFüge das volle JWT inklusive beider Punkte ein. Die drei Segmente werden automatisch gesplittet und decodiert.
  2. Lies den HeaderEr nennt den Signaturalgorithmus – HS256, RS256 und so weiter – und den Token-Typ. Das ist das Erste, das du prüfst, wenn die Verifikation scheitert.
  3. Lies die Payload-ClaimsDie Claims werden als formatiertes JSON gezeigt. Schau nach exp (Ablauf), iat (issued at), iss (Issuer), aud (Audience) und sub (Subject).
  4. Prüfe den Ablaufexp und iat sind Unix-Timestamps in Sekunden. Ein abgelaufenes Token ist die häufigste einzelne Ursache für einen 401, der „gestern noch ging“.

Warum es nutzen

  • Zeigt genau, was ein Token behauptet, das macht aus Raten einen Zwei-Sekunden-Check beim Debuggen von Auth.
  • Formatiert das Payload als lesbares JSON statt einer Wand encodierter Zeichen.
  • Behandelt Base64url korrekt, Tokens decodieren also dort, wo ein schlichter Base64-Decoder scheitert.
  • Läuft in deinem Browser – das Token wird nie an einen Server übertragen.
  • Kein Konto und kein Ratenlimit.

Häufige Anwendungen

  • Einen 401 debuggen, indem du prüfst, ob das Token wirklich abgelaufen ist.
  • Bestätigen, dass ein Login-Flow die Rollen, Scopes oder Berechtigungen ausstellt, die du erwartest.
  • Audience- und Issuer-Claims prüfen, wenn ein Token von einer API abgelehnt wird.
  • Ein Token von einem Drittanbieter-Identity-Provider inspizieren, um zu sehen, was drin ist.
  • Lernen, wie JWTs strukturiert sind, während du Authentifizierung implementierst.

Tipps für bessere Ergebnisse

  • Prüfe exp zuerst. Timestamps sind Unix-Sekunden, nicht Millisekunden – ein Wert wie 1767225600 sind Sekunden; JavaScripts Date.now() gibt Millisekunden.
  • Ein Mismatch zwischen dem aud-Claim und dem, was die API erwartet, ist die zweithäufigste Ablehnung nach Ablauf.
  • Das alg im Header sagt dir, womit der Server verifizieren muss. Steht dort „none“, behandle das Token als untrusted.
  • Nutze ein abgelaufenes oder Test-Token, wenn du nur die Struktur erkundest – Gewohnheit zählt mehr als dass irgendein einzelnes Tool sicher ist.
  • Um signierte Tokens zum Testen zu erzeugen statt sie zu lesen, nutze den JWT Encoder.

Fehler, die du vermeiden solltest

  • Annehmen, das Payload sei privat. Es ist für jeden lesbar, der das Token hält, personenbezogene Daten und Secrets gehören also nicht hinein.
  • Ein erfolgreiches Decode als Beweis behandeln, das Token sei gültig. Decodieren ignoriert die Signatur ganz.
  • JWTs in localStorage speichern, wo jedes XSS sie lesen kann. Ein httpOnly-Cookie ist der sicherere Default.
  • exp als Millisekunden lesen und schließen, ein gültiges Token sei abgelaufen, oder umgekehrt.
  • Ein Live-Produktions-Token, das echten Zugriff gewährt, aus Gewohnheit in irgendeine Drittanbieter-Seite einfügen.

Unterstützte Formate

  • JWT

Verfügbare Optionen

  • Decode header
  • Decode payload

Häufig gestellte Fragen

Füge das Token oben ein. Header und Payload werden sofort als formatiertes JSON decodiert und gezeigt – kein Key ist nötig, weil diese Segmente nur encodiert sind.

Ja. Kein Konto, kein Limit, und das Token verlässt deinen Browser nie.

Nein. Decodieren liest Header und Payload; es prüft die Signatur nicht. Ein decodiertes Token sagt dir, was es behauptet, nicht ob es echt oder unverändert ist – das kann nur der Server mit dem Signing-Key bestimmen.

Nein. Es ist Base64url-encodiert, also von jeder Person umkehrbar. Die Signatur schützt vor Manipulation, nicht vor Lesen, lege also nie vertrauliche Daten in ein Payload.

Header (Signaturalgorithmus und Token-Typ), Payload (die Claims) und Signatur (beweist, dass die ersten zwei nicht geändert wurden). Sie sind durch Punkte getrennt und jedes ist Base64url-encodiert.

Schau auf den exp-Claim, einen Unix-Timestamp in Sekunden. Vergleiche ihn mit der aktuellen Zeit in Sekunden – ist exp kleiner, ist das Token abgelaufen, die übliche Ursache für einen plötzlichen 401.

Decodieren passiert lokal und nichts wird übertragen. Trotzdem: Vermeide es als Gewohnheit, Produktions-Tokens mit echtem Zugriff in irgendein Drittanbieter-Tool einzufügen – nutze ein abgelaufenes oder Test-Token, wenn du nur die Struktur inspizierst.

iss ist der Issuer, sub das Subject (meist eine User-ID), aud die intended Audience, exp der Ablauf, iat wann es ausgestellt wurde und nbf die früheste Zeit, zu der es gültig ist. Alles andere ist ein Custom-Claim des ausstellenden Systems.

Andere suchen auch nach

  • jwt decoder online kostenlos
  • jwt token kostenlos decodieren
  • jwt debugger online
  • ist jwt payload verschlüsselt
  • jwt ablauf prüfen
  • jwt gegen session token
  • json web token erklärt

Useful in

Related guides