Header, Payload und Signatur dekodiert
Die kompakte Serialisierung wird in ihre drei Base64URL-Segmente zerlegt; Header und Payload erscheinen als formatiertes JSON, das Signatursegment unverändert.
JWT Decoder
JSON Web Tokens lokal prüfen
Header, Payload und Claims im Browser dekodiert, ohne dass etwas versendet wird.
Web-Tool
Offizielle Produktseite
Herausgeber:
POLPROG
Offizielle Produktseite
3
Dekodierte Token-Segmente
7
Geprüfte registrierte Claims
50 000
Maximale Tokenlänge
0
An einen Server gesendete Daten
01/JWT Decoder
Über
Es dekodiert. Es verifiziert nicht, und es behauptet nie etwas anderes. Dekodieren packt aus, was ein Token über sich selbst sagt; zu beweisen, dass ein Token echt ist, heißt seine Signatur gegen den geheimen oder öffentlichen Schlüssel zu prüfen, der sie erzeugt hat. Dieses Tool fragt nicht nach einem Schlüssel und bekommt nie einen, deshalb wird die Signatur als nicht verifiziert gemeldet statt still als in Ordnung dargestellt.
Die drei Segmente
| Segment | Was damit geschieht |
|---|---|
| HeaderDekodiert | Base64URL-dekodiert und als formatiertes JSON gezeigt, mit dem daraus gelesenen Algorithmus. |
| PayloadDekodiert | Base64URL-dekodiert und als formatiertes JSON gezeigt, mit den herausgezogenen und benannten registrierten Claims. |
| SignaturSo gezeigt, wie sie ist | Angezeigt, nie geprüft. Eine Prüfung bräuchte den Schlüssel. |
Die Claims, benannt
Die sieben registrierten Claims aus RFC 7519 und dem IANA-Register - iss, sub, aud, exp, nbf, iat und jti - werden aus dem Payload gezogen und bekommen ihre richtigen Namen: Aussteller, Subjekt, Zielgruppe, Ablaufzeit, nicht vor, ausgestellt am und JWT-ID. Alles andere, was Ihr System in das Token gelegt hat, bleibt im dekodierten Payload sichtbar, statt versteckt zu werden, weil es nicht standardisiert ist.
Zeiten in Worten statt in Zahlen
exp, iat und nbf sind NumericDate-Werte, also Sekunden seit dem 1. Januar 1970 UTC. Roh gelesen sagen sie nichts, deshalb werden sie mit der aktuellen Zeit verglichen und als wie viel Zeit bleibt, wie lange das Token schon ausgestellt ist oder wann es aktiv wird gemeldet. Das ist meist die ganze Frage, wenn ein Token aufgehört hat zu funktionieren.
alg: none wird benannt, nicht übergangen
Ein ungesichertes Token trägt überhaupt keine kryptografische Signatur. RFC 7519 erlaubt es für bestimmte interne Fälle, und es bietet keinerlei Manipulationsschutz, deshalb wird es ausdrücklich markiert, statt wie ein Token zu wirken, das zufällig ein kurzes drittes Segment hat. Eine fehlende Signatur darf nie für eine erfüllte gehalten werden.
Ein fehlerhaftes Token bekommt einen Grund
Eine falsche Anzahl Segmente, kaputtes Base64URL und ungültiges JSON in einem Segment erzeugen jeweils eine eigene Meldung. Der Fehlschlag sagt, welcher der drei Fälle es war, statt ein leeres Ergebnis zu liefern und Sie raten zu lassen, ob das Token abgeschnitten, beschädigt oder schlicht kein JWT ist.
Hinter dieser Seite steht kein API-Endpunkt. Das Token wird im Browserspeicher dekodiert und nie hochgeladen, protokolliert oder gespeichert, was hier mehr zählt als bei den meisten Tools: ein produktives Zugriffstoken, das auf der Website eines anderen eingefügt wird, ist ein Zugangsgeheimnis, das Sie gerade preisgegeben haben.
02/Einsatz
Was es löst
Das Problem
- Der Inhalt eines Tokens bleibt undurchsichtig, bis ihn etwas dekodiert
- Produktions-Tokens landen auf einer fremden Website
- exp und iat müssen als rohe Unix-Zahlen gelesen werden
Das Ergebnis
- Header, Claims und Zeitverhalten sind sofort lesbar
- Der Token verlässt das eigene Gerät nie
- Der Ablauf steht in Worten da, nicht als Zeitstempel
Für wen
- Entwickler, die APIs und OAuth-Abläufe integrieren
- Engineers, die Authentifizierung und Sessions debuggen
- Alle, die prüfen, warum ein Token nicht mehr funktioniert
03/Hauptfunktionen
Hauptfunktionen
Die wichtigsten Funktionen praxisnah erklärt.
Inspektor für registrierte Claims
Die Standard-Claims nach RFC 7519 / IANA - iss, sub, aud, exp, nbf, iat und jti - werden aus dem Payload herausgelöst und benannt; eigene Claims bleiben im dekodierten Payload sichtbar.
Ablauf und Zeitverhalten in klaren Worten
exp, iat und nbf sind NumericDate-Werte. Das Tool vergleicht sie mit der aktuellen Zeit und nennt die Restlaufzeit, den Ausstellungszeitpunkt oder den Beginn der Gültigkeit.
Die Signatur gilt nie als verifiziert
Das Tool dekodiert ausschließlich. Es nennt den Algorithmus und markiert die Signatur als nicht verifiziert, denn die Prüfung bräuchte den Schlüssel.
alg: none wird deutlich markiert
Ein ungesicherter Token wird ausdrücklich gekennzeichnet, damit eine fehlende Signatur nie für eine gültige gehalten wird.
Fehlerhafte Tokens werden erklärt
Eine falsche Segmentzahl, defektes Base64URL oder ungültiges JSON ergeben jeweils eine eigene Meldung statt eines leeren Ergebnisses.
Nichts verlässt den Browser
Das Tool hat keinen API-Endpunkt. Der Token wird im Browserspeicher dekodiert und nie hochgeladen, protokolliert oder gespeichert.
04/Herunterladen
Produktzugang
Ein klarer Weg von der offiziellen Quelle bis zum ersten erfolgreichen Einsatz.
Passende Plattform wählen
Nutzen Sie einen der offiziellen Links für Ihr Gerät oder Ihren Browser.
Installieren oder öffnen
Folgen Sie den Store-Anweisungen oder öffnen Sie die Webanwendung. Keine Drittanbieter-Installer.
Konfigurieren und starten
Prüfen Sie die Optionen, wählen Sie Ihre Einstellungen und beginnen Sie mit dem zentralen Workflow.
Offizielle Zugangsoptionen
05/Technologie
Technologie des Produkts
Ein transparenter Blick auf die Kerntechnologien für Entwicklung und Wartung dieses Produkts.
JavaScript
06/Sicherheit
Datenschutz & Sicherheit
Ihre Daten bleiben auf Ihrem Gerät. Immer.