JWT-Decoder & -Verifizierer
JSON Web Tokens dekodieren und HS/RS/ES/PS-Signaturen prüfen — komplett im Browser
—
—
Was ist ein JWT-Decoder?
Ein JWT (JSON Web Token) ist ein Token aus drei Teilen – Header, Payload, Signatur – das in modernen Web-Apps für Authentifizierung und Autorisierung genutzt wird. Der Payload sieht aus wie Zufallstext, bis man ihn decodiert – genau das tut dieses Tool. Es macht aus Header und Payload lesbares, hübsch formatiertes JSON, erklärt registrierte Claims wie exp, nbf und iat in verständlicher Sprache mit echten Daten und zeigt, ob das Token abgelaufen, aktiv oder noch nicht gültig ist. Es kann auch Signaturen verifizieren: HS256/384/512 mit einem geteilten Geheimnis und RS/PS/ES mit einem PEM-öffentlichen Schlüssel – alles per Web Crypto im Browser. Für Entwickler, die Auth-Flows debuggen, ersetzt das die Gewohnheit, Produktionstokens auf fremde Websites zu kleben.
Was dieses Tool kann
- 📖 Header und Payload in hübsch formatiertes JSON decodieren
- 🏷️ Registrierte Claims verständlich erklären
- ⏳ exp, nbf und iat als exakte Daten plus relative Zeit anzeigen
- ✅ Signaturprüfung für HS256/384/512 mit Geheimnis
- 🔏 Signaturprüfung für RS/PS/ES mit PEM-öffentlichem Schlüssel
- 🚦 Status-Badge: abgelaufen, aktiv oder noch nicht gültig
- ⚠️ Warnung, wenn der alg-Header none ist, also kein gesichertes Token vorliegt
Wann Sie es brauchen
- Wenn Sie einen 401-Fehler im Login-Flow debuggen
- Wenn Sie herausfinden wollen, warum ein Token plötzlich nicht mehr funktioniert
- Wenn Sie ein Token eines Drittanbieters verifizieren, bevor Sie ihm vertrauen
- Wenn Sie die Claims in einem Refresh-Token ansehen möchten
Datenschutz: Tokens und Schlüssel werden vollständig im Browser verarbeitet und nie hochgeladen – echte Produktions-Zugangsdaten können bedenkenlos eingefügt werden.
Was die drei Segmente tatsächlich sind
Ein JWT besteht aus drei base64url-kodierten Segmenten, die durch Punkte getrennt sind:
- Header benennt den Algorithmus; Payload enthält die Claims; Signatur bindet beide Segmente unter einem Geheimnis oder Schlüssel zusammen.
- Nichts im Header oder in der Payload ist verschlüsselt – jeder, der das Token besitzt, kann alle Claims lesen. Das ist Absicht: JWT ist ein signierter Container, kein sicherer Speicher.
- Zur Verifizierung benötigen Sie den Signaturschlüssel, und sie erfolgt auf Ihrem Server; diese Seite decodiert lokal, sodass Sie die Claims prüfen können, ohne das Token irgendwo extern einzufügen.
Decodieren ist nicht Verifizieren
Claims werden echte Daten
Header und Payload erscheinen als lesbares JSON, während registrierte Claims wie exp, nbf und iat zu echten Datumsangaben werden, mit klarem Urteil: abgelaufen, aktiv oder noch nicht gültig.
HS-, RS-, PS- und ES-Verifikation
HS256/384/512 lassen sich gegen ein gemeinsames Geheimnis in Klartext- oder Base64-Form prüfen, RS-, PS- und ES-Tokens gegen einen PEM-öffentlichen Schlüssel — per Web Crypto direkt auf der Seite.
Fehlerhafte Tokens erklärt
Strukturprobleme werden präzise gemeldet — fehlender Punkt, ungültiger Header, unlesbarer Payload — und Tokens, die den none-Algorithmus beanspruchen, werden markiert statt vertraut.
Häufige Fragen
Wird mein Token an einen Server gesendet?⌄
Nein. Dekodierung und Signaturprüfung erfolgen vollständig im Browser mit der Web Crypto API. Token, Secret und Schlüssel verlassen Ihr Gerät nie, sodass auch Produktions-Tokens sicher geprüft werden können.
Welche Signaturalgorithmen können geprüft werden?⌄
HS256/384/512 mit gemeinsamem Secret (UTF-8 oder base64url) sowie die asymmetrischen Familien RS256/384/512, PS256/384/512 und ES256/384/512 durch Einfügen des PEM-Public-Keys. Für asymmetrische Tokens brauchen Sie nur den öffentlichen Schlüssel, nie den privaten.
Ein JWT ist nicht verschlüsselt — was bedeutet das?⌄
Ein Standard-JWT ist nur base64url-kodiert und signiert, nicht verschlüsselt, sodass jeder den Payload lesen kann. Legen Sie niemals Geheimnisse in ein JWT. Die Signatur belegt nur, dass das Token nicht ohne den Schlüssel manipuliert wurde.
Es steht „Signatur ungültig“ — ist das Token gefälscht?⌄
Meistens einer von drei langweiligen Gründen: Das Token wurde mit dem Geheimnis einer anderen Umgebung signiert; der Aussteller rotiert die Schlüssel und Ihr Schlüssel ist veraltet; oder der Algorithmus im Header stimmt nicht mit dem überein, den Ihr Verifizierer erwartet (der berüchtigte <code>alg=none</code>-Trick). Decodieren Sie zunächst den Header hier, und vergleichen Sie ihn dann mit dem Schlüssel, den Ihr Backend tatsächlich verwendet.