Alle Tools

JWT-Decoder

JSON Web Tokens decodieren und prüfen (Header, Payload, Ablauf)

So funktioniert es

JWT-DecoderJSON Web Tokens decodieren und prüfen (Header, Payload, Ablauf). Alle Verarbeitung erfolgt in deinem Browser — kein Upload, keine Anmeldung, keine E-Mail. Für immer kostenlos.

Zuletzt aktualisiert:

Über JWT-Decoder

Ein JSON Web Token sieht aus wie ein undurchsichtiger String aus Punkten und Base64, aber innen steckt ein perfekt lesbarer JSON-Header und -Payload — plus eine Signatur, die beweist, dass der Issuer ihn ausgestellt hat. Dieser JWT Decoder splittet die drei Segmente, base64url-dekodiert sie, formatiert das JSON sauber und konvertiert die Standard-Zeit-Claims (iat, nbf, exp) in deine lokale Zeitzone, damit du sofort siehst, ob ein Token abgelaufen ist, wann er ausgestellt wurde und für wen.

Decoden ist genau das, was Backend-Entwickler dutzendfach pro Woche machen: Eine API liefert 401 zurück, du kopierst den Bearer-Token, du willst "sub", "aud", "scope" und "exp" sehen, ohne Node oder Python hochzufahren. Das in einem zufälligen Online-Tool zu machen ist riskant, weil Tokens oft E-Mail-Adressen, interne User-IDs, Rollen-Claims und Tenant-Identifier enthalten — genau die Daten, die ein Drittanbieter nicht loggen sollte.

Alles in diesem Decoder passiert client-seitig in deinem Browser. Der Token verlässt dein Gerät nie, wird an keinen Server gesendet, nicht in localStorage gespeichert und verschwindet, wenn du den Tab schließt. Die Signatur wird bewusst nicht geprüft — dafür bräuchte es das Geheimnis oder den Public Key des Issuers, den wir niemals abfragen. Für kryptographische Validierung nutzt du dein Backend oder eine JWT-Library. Insbesondere bei Tokens mit sensiblen Claims (Mitarbeiter-IDs, interne Scopes, PII) bleibt so garantiert nichts in fremden Logs hängen.

So verwenden Sie JWT-Decoder

  1. Füge das JWT (den langen "xxx.yyy.zzz"-String) ins Eingabefeld ein.
  2. Lies den dekodierten Header, um den Algorithmus (alg) und die Key-ID (kid) des Issuers zu sehen.
  3. Inspiziere den Payload auf Claims wie sub, aud, iss, scope und alle Custom-Felder, die dein Service injiziert hat.
  4. Prüfe den Zeitstempel-Bereich — "Läuft ab", "Ausgestellt am" und "Nicht vor" werden in deine lokale Zeitzone konvertiert.
  5. Schau auf das "Gültig"-/"Abgelaufen"-Badge für einen schnellen Check und kopiere bei Bedarf einzelne Claims.
  6. Denk daran: Die Signatur wird angezeigt, aber nicht verifiziert — für kryptographische Validierung gib den Token an dein Backend.

Häufige Anwendungsfälle

  • "401 Unauthorized"-Antworten debuggen, indem du prüfst, ob der Bearer-Token tatsächlich abgelaufen ist.
  • Einen OAuth2- oder OIDC-Access-Token inspizieren, um zu bestätigen, dass Scopes, Audience und Issuer dem entsprechen, was die API erwartet.
  • Custom-Claims (Tenant-ID, Rolle, Feature-Flags) lesen, die dein Auth-Provider beim Login hinzugefügt hat.
  • Clock-Skew-Probleme bestätigen, wenn "nbf" (not before) ein paar Sekunden in der Zukunft relativ zum Server liegt.
  • Eine redigierte Sicht eines Tokens mit einem Teamkollegen teilen, ohne ihn in Slack oder eine öffentliche Site zu kopieren.

Tipps und häufige Fehler

  • Wenn das Decoden fehlschlägt, prüfe, ob du den vollen Token inklusive beider Punkte kopiert hast — viele UIs schneiden am ersten Leerzeichen ab oder verstecken die abschließende Signatur.
  • Ein dekodierter Payload beweist nichts über Echtheit. Jeder kann ein gültig aussehendes JWT erzeugen; nur die Signaturprüfung mit dem Schlüssel des Issuers zeigt, dass es echt ist.
  • Behandle JWTs wie Passwörter beim Teilen von Screenshots — selbst "abgelaufene" Tokens können User-IDs, E-Mail-Adressen und interne Scope-Namen leaken.
  • Wenn "alg" im Header "none" ist, hat der Token gar keine Signatur und dein Service muss ihn ablehnen. Dieser Decoder zeigt den Payload trotzdem an, damit du den Bug bestätigen kannst.

Häufig gestellte Fragen

Wird das Token an euren Server gesendet?

Nein. Die Dekodierung erfolgt vollständig in deinem Browser mit JavaScript — das Token verlässt dein Gerät nie.

Verifiziert das die Signatur?

Nein. Dieses Tool dekodiert nur Header und Payload. Signaturprüfung erfordert den geheimen/öffentlichen Schlüssel, den wir nie anfordern — nutze dafür dein Backend oder eine JWT-Bibliothek.

Warum werden Datumsangaben in meiner lokalen Zeitzone angezeigt?

Standard-JWT-Claims wie exp, iat und nbf sind Unix-Timestamps (UTC). Wir rendern sie zur Lesbarkeit in der lokalen Zeitzone deines Browsers.

Schickt dieses Tool meinen Token jemals an einen Server?

Nein. Das Decoden ist reines JavaScript, das in deinem Browser-Tab läuft. Kein fetch, keine Telemetrie, kein Logging. Öffne DevTools → Network und du siehst null Requests, wenn du einen Token einfügst.

Kann es auch verschlüsselte JWE-Tokens dekodieren?

Nein. JWE (verschlüsselte JWTs) brauchen den privaten Schlüssel des Empfängers, um lesbar zu sein. Dieses Tool verarbeitet nur JWS (signierte JWTs) — und das ist, was die meisten OAuth2- und OIDC-Flows tatsächlich ausstellen.

Warum zeigt der Payload numerische Zeitstempel und ein menschliches Datum?

Standard-Claims (exp, iat, nbf) werden als Unix-Sekunden in UTC gespeichert. Wir zeigen die rohe Zahl plus ein konvertiertes Datum in der lokalen Zeitzone, damit du Ablauf-Probleme ohne Rechnen siehst.

Ähnliche Tools