acento.io
Entwickler-Tool

JWT-Decoder

Dekodiere jeden JWT-Token direkt im Browser – sicher, schnell und ohne Datenübertragung an Server.

Von Carlos Suárez , Systeminformatiker
Zuletzt aktualisiert:

Was dieser JWT-Decoder macht

JSON Web Tokens (JWT) begegnen dir in fast jedem modernen OAuth- und OpenID-Connect-Flow. Doch was steckt wirklich drin? Dieser JWT-Decoder für deutschsprachige Entwicklerinnen und Entwickler zerlegt jeden Token sofort in seine drei Bestandteile: Header, Payload und Signatur. Du siehst alle Standard-Claims – iss, sub, aud, exp, iat, nbf, jti – farblich hervorgehoben und erfährst auf Anhieb, ob der Token bereits abgelaufen ist. Wichtig: Dekodieren bedeutet nicht Verifizieren. Die Signatur lässt sich nur mit dem geheimen oder öffentlichen Schlüssel prüfen – und den solltest du niemals in ein Online-Tool eingeben. Diese Seite führt keinerlei Signaturprüfung durch, was sie sicher für Tokens mit personenbezogenen Daten macht. 100% im Browser – deine Daten verlassen nie dein Gerät. Keine Uploads, kein Tracking, keine Server-Logs. Übrigens: JWT folgt RFC 4648 für die Base64URL-Kodierung der einzelnen Segmente – ein subtiler Unterschied zum klassischen Base64, der Padding-Zeichen weglässt.

Funktionen

  • Sofortige Token-Dekodierung. Füge einen JWT-Token ein – mit oder ohne 'Bearer '-Präfix – und sieh Header und Payload unmittelbar dekodiert, ohne Seitenaufruf.
  • Ablaufstatus auf einen Blick. Der exp-Claim wird automatisch ausgewertet: Du siehst sofort, ob der Token noch gültig ist oder wann er abgelaufen ist – hilfreich beim Debuggen von Auth-Fehlern.
  • Standard-Claims hervorgehoben. iss, sub, aud, exp, iat, nbf und jti werden gesondert dargestellt, damit du Aussteller- und Audience-Konflikte schnell erkennst.
  • Algorithmus-Anzeige. Der alg-Wert im Header (z. B. HS256, RS256, ES256) wird explizit angezeigt – inklusive Hinweis, wenn alg=none gesetzt ist, was ein bekanntes Sicherheitsrisiko darstellt.
  • Kein Datentransfer. Alles läuft im Browser via JavaScript. Dein Token verlässt nie dein Gerät – kein Server, kein Log, kein Tracking.
  • Kopieren per Klick. Header und Payload lassen sich mit einem Klick in die Zwischenablage kopieren, um sie direkt in Tests oder Logs weiterzuverarbeiten.

So benutzt du den JWT-Decoder

Token einfügen, fertig. Kein Login, keine Konfiguration – der Decoder arbeitet sofort.

  1. Token einfügen. Kopiere deinen JWT-Token aus dem Authorization-Header, dem Browser-DevTools-Netzwerk-Tab oder deinem Auth-Provider und füge ihn in das Eingabefeld ein.
  2. Ergebnis lesen. Header, Payload und Signatur erscheinen sofort getrennt. Claims wie exp und iat werden als lesbare Zeitstempel (Europe/Zurich-kompatibel) dargestellt.
  3. Ablaufstatus prüfen. Das Tool zeigt dir direkt, ob der Token abgelaufen ist oder noch wie lange er gültig ist – ideal beim Debuggen von 401-Fehlern in OAuth-Flows.
  4. Manuell nachvollziehen. Willst du den Payload selbst dekodieren? In JavaScript geht das mit JSON.parse(atob(token.split('.')[1])) – oder in der Shell: echo $token | cut -d. -f2 | base64 -d | jq .
  5. Ergebnis kopieren. Klicke auf „Kopieren“ neben Header oder Payload, um die JSON-Daten direkt in deine IDE, Logs oder einen API-Test zu übernehmen.

Häufige Anwendungsfälle

  • OAuth-Debugging. Wenn ein API-Aufruf mit 401 fehlschlägt, dekodierst du den Access-Token sofort und prüfst, ob aud, iss oder exp die Ursache sind – ohne Zugriff auf den Auth-Server.
  • Integration Tests vorbereiten. Vor dem Schreiben von Tests prüfst du das genaue Format der Claims deines Identity-Providers, damit deine Assertions gegen die richtigen Felder laufen.
  • Custom Claims lesen. Viele Auth-Provider wie Keycloak oder Auth0 fügen eigene Claims ein (Rollen, Mandanten-IDs). Hier siehst du sie auf einen Blick – auch für Bearer-Token aus Produktionslogs.
  • Token-Format validieren. Bevor du eine neue JWT-Bibliothek in dein Berliner oder Kölner Backend integrierst, überprüfst du, ob Token-Struktur und Algorithmus deinen Anforderungen entsprechen.
  • Sicherheitsreviews. Im Code-Review lässt sich schnell prüfen, ob ein Token versehentlich alg=none setzt oder sensible Daten im Payload unverschlüsselt enthält – JWT ist signiert, nicht verschlüsselt (das wäre JWE).

Häufig gestellte Fragen

Ist es sicher, echte Tokens hier einzufügen?

Ja – dieses Tool läuft vollständig im Browser. Dein Token wird an keinen Server gesendet, nicht gespeichert und nicht geloggt. Für Tokens mit sensitiven Nutzdaten ist das die sicherste Option: kein Drittserver sieht deine Daten.

Was ist der Unterschied zwischen Dekodieren und Verifizieren?

Dekodieren bedeutet lediglich, die Base64URL-kodierten Segmente lesbar zu machen – das kann jeder ohne Schlüssel tun. Verifizieren bedeutet, die Signatur mit dem geheimen oder öffentlichen Schlüssel zu prüfen, um sicherzustellen, dass der Token unverändert und von einer vertrauenswürdigen Stelle ausgestellt wurde. Für Authentifizierungsentscheidungen brauchst du immer die Verifikation.

Warum sehe ich manchmal 'alg: none' im Header?

'alg=none' bedeutet, dass kein Signaturalgorithmus verwendet wird. Das ist ein bekannter Angriffspfad: Angreifer manipulieren den Header, um Signaturprüfungen zu umgehen. Gut gewartete Bibliotheken lehnen solche Tokens ab. Siehst du alg=none in einem produktiven Token, ist das ein ernstes Sicherheitsproblem.

Kann ich diesen Decoder für verschlüsselte JWTs (JWE) verwenden?

Nein. JWE-Token sind verschlüsselt – ihre Payload ist ohne den privaten Schlüssel nicht lesbar. Dieser Decoder ist für signierte JWTs (JWS) gemäß RFC 4648-konformer Base64URL-Kodierung gedacht, nicht für verschlüsselte Token.

Warum sind Umlaute oder Sonderzeichen im Payload manchmal falsch?

JWT-Payloads sind UTF-8-kodiert und dann Base64URL-kodiert. Umlaute wie ä, ö, ü und ß werden in UTF-8 als Zwei-Byte-Sequenzen dargestellt – ein häufiger Fehlerquelle in Legacy-Systemen, die fälschlicherweise Latin-1 annehmen. Dieser Decoder gibt UTF-8 korrekt aus.

Was bedeutet 'Bearer' vor dem Token?

'Bearer' ist ein HTTP-Authentifizierungsschema gemäß dem OAuth-Standard und zeigt an, dass der Inhaber des Tokens Zugriff erhält. Das eigentliche JWT folgt nach dem Leerzeichen. Dieses Tool akzeptiert den Token mit oder ohne dieses Präfix.