Einen 401-Fehler analysieren
Eine API lehnt deine Anfrage ab: Dekodiere das Bearer-Token und prüfe, ob es abgelaufen ist, ob die Zielgruppe aud zur aufgerufenen API passt oder ob der Aussteller iss zur richtigen Umgebung gehört.
Füge ein JSON Web Token ein: Header und Payload werden während der Eingabe zu JSON dekodiert, mit einer Übersicht über Algorithmus, Aussteller, Zielgruppe und die Zeitpunkte exp, iat und nbf in Ortszeit.
algtypkidisssubaudexpiatnbfDas Dekodieren prüft die Signatur nicht: Jeder kann ein JWT lesen. Um die Signatur zu prüfen, nutze den JWT-Verifier.
Der JWT-Decoder zeigt Header und Payload eines JSON Web Tokens als lesbares JSON an, sobald du es einfügst. Er richtet sich an Entwickler, Tester und Support-Teams, die schnell verstehen müssen, was ein Access Token oder ID Token enthält: Algorithmus, Aussteller, Zielgruppe und Gültigkeitszeitraum. Er liest das Token, prüft aber nicht seine Signatur.
Ein signiertes JWT (RFC 7519, im kompakten JWS-Format aus RFC 7515) besteht aus drei durch Punkte getrennten Segmenten: Header, Payload und Signatur. Die ersten beiden sind JSON in Base64URL-Kodierung, einer Base64-Variante, die + und / durch - und _ ersetzt und das Auffüllzeichen = weglässt. Der Decoder zerlegt das Token, wandelt jedes Segment in UTF-8-Text um und parst es als JSON. So entspricht das Segment eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 dem Objekt {"alg":"HS256","typ":"JWT"}.
Die Übersicht zieht anschließend die wichtigen Felder heraus: alg und typ aus dem Header, iss (Aussteller), sub (Subjekt) und aud (Zielgruppe) aus der Payload. Die Claims exp, iat und nbf sind NumericDate-Werte, also Sekunden seit dem 1. Januar 1970 UTC: 1767225600 entspricht dem 1. Januar 2026 um 00:00 UTC. Das Tool rechnet sie in Ortszeit um und zeigt, ob das Token gültig, abgelaufen oder noch nicht gültig ist. Deklariert der Header alg: none, also ein unsigniertes Token, erscheint eine Warnung.
Füge das vollständige Token mit seinen drei durch Punkte getrennten Teilen ein. Die Dekodierung startet schon während der Eingabe, ohne Klick.
Beide Segmente erscheinen als formatiertes JSON: Algorithmus und Typ im Header, Standard- und eigene Claims in der Payload.
Kontrolliere Algorithmus, iss, sub, aud sowie exp, iat und nbf in Ortszeit mit ihrem Status. Für die Signaturprüfung wechselst du zum JWT-Verifizierer.
Eine API lehnt deine Anfrage ab: Dekodiere das Bearer-Token und prüfe, ob es abgelaufen ist, ob die Zielgruppe aud zur aufgerufenen API passt oder ob der Aussteller iss zur richtigen Umgebung gehört.
Nach einem OpenID-Connect-Login (Auth0, Keycloak, Entra ID, Cognito) siehst du eigene Claims wie roles, groups oder scope und verstehst, warum ein Nutzer keinen Zugriff auf eine Seite hat.
Vergleiche iat und exp, um sicherzugehen, dass dein Identity Provider Access Tokens wirklich mit 5, 15 oder 60 Minuten Laufzeit ausstellt, wie in deiner Konfiguration vorgesehen.
Eingabe
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cErgebnis
Header: {"alg":"HS256","typ":"JWT"}; Payload: {"sub":"1234567890","name":"John Doe","iat":1516239022}; Signatur nicht geprüft (das Dekodieren prüft die Signatur nicht)Ja. Header und Payload sind nur Base64URL-kodiert, nicht verschlüsselt, daher kann jeder mit dem Token sie lesen. Der Schlüssel wird nur für die Signaturprüfung gebraucht, und die übernimmt der JWT-Verifizierer, nicht dieser Decoder.
Nein, ein signiertes JWT (JWS) kann jeder lesen; die Signatur belegt nur, dass es nicht verändert wurde. Lege deshalb nie Passwörter oder vertrauliche Daten in die Payload. Muss der Inhalt geheim bleiben, brauchst du ein JWE (RFC 7516).
exp ist der Ablaufzeitpunkt, iat der Ausstellungszeitpunkt und nbf der Zeitpunkt, vor dem das Token nicht akzeptiert werden darf. Es sind Unix-Sekunden (NumericDate, RFC 7519), keine Millisekunden. Das Tool zeigt sie in Ortszeit mit dem Status gültig, abgelaufen oder noch nicht gültig.
alg: none bedeutet, dass das Token gar nicht signiert ist. Ein Server, der es akzeptiert, lässt jeden eigene Tokens erzeugen – eine bekannte Schwachstelle, die RFC 8725 beschreibt. Eine Produktivanwendung muss immer eine feste Liste erlaubter Algorithmen erzwingen.
Oft wurde das Token beim Kopieren abgeschnitten, enthält noch das Präfix Bearer oder Anführungszeichen oder hat keine drei Segmente. Auch ein Segment, das kein gültiges Base64URL ist oder dessen Inhalt kein JSON ist, führt zu einem Fehler.
Ein gültiges Access Token ist ein Zugangsnachweis: Wer es hat, kann es bis zum Ablauf nutzen. Hier läuft die Dekodierung in deinem Browser, und das Token wird an keinen Server geschickt. Nimm trotzdem nach Möglichkeit Test- oder bereits abgelaufene Tokens.
Empfohlener Workflow
Entdecke Werkzeuge, die sinnvoll vor, nach oder ergänzend zu diesem Werkzeug eingesetzt werden können.
Kodiere Text als Base64 oder dekodiere Base64 zurück in lesbaren Text.
Formatiere, komprimiere und prüfe JSON-Daten.
Berechne MD5-, SHA-1-, SHA-256-, SHA-384- und SHA-512-Hashes eines Textes oder einer Datei auf einmal.
Prüfe die Signatur eines JWT mit einem HMAC-Secret oder einem öffentlichen Schlüssel als JWK, JWKS oder PEM und kontrolliere exp, nbf, iss und aud.
Lerne, was ein JWT enthält, warum Dekodieren keine Verifikation ist und wie Claims wie exp, nbf, iss und aud funktionieren.
Verstehe das Zusammenspiel von OAuth 2.0, PKCE, JWT, JWK und JWKS bei Autorisierung, Tokens, Schlüsseln und Verifizierung.
Verstehe, wann Verschlüsselung, Hashing, HMAC oder PBKDF2 für Vertraulichkeit, Integrität, Authentifizierung und Passwörter eingesetzt werden.