JWT Dekodieren — Header und Payload Lesen
Dekodieren Sie ein JWT, um Header und Payload klar zu lesen — sofort und privat in Ihrem Browser.
Das Token bleibt auf dem Gerät
Nichts, was später zu löschen wäre
Für aktive Zugangsdaten gebaut
Läuft in jedem modernen Browser
So funktioniert es
- 1
Token einfügen
Vollständig, mit beiden Punkten — die drei Teile werden dadurch getrennt.
- 2
Claims lesen
Kopf auf der einen Seite, Nutzlast auf der anderen, Zeitstempel in Datumsform.
- 3
Prüfen, weshalb Sie hier sind
Meist der Ablauf, der Aussteller, das Publikum oder für welche Nutzerin das Token eigentlich gilt.
Warum dieses Tool
Kopf und Nutzlast nebeneinander
Algorithmus und Schlüsselhinweis neben den Claims — dort werden die meisten Debugging-Fragen beantwortet.
Zeitstempel in lesbarer Form
`exp`, `iat` und `nbf` als Datum statt als zehnstellige Zahlen, die Sie erst umrechnen müssten.
Ablauf gegen jetzt geprüft
Sie sehen sofort, ob das Token noch in seinem Fenster liegt, ohne zu rechnen.
Ehrlich zur Prüfung
Dieses Werkzeug dekodiert; es prüft keine Signatur und sagt das, statt Gültigkeit zu suggerieren.
Nichts wird übertragen
Das Token wird in Ihrem Browser geparst — ein funktionierendes Sitzungsdatum erreicht nie einen Server.
Kostenlos, ohne Konto
Keine Anmeldung, kein Wasserzeichen, keine Obergrenze für die Zahl der Token.
Dekodieren ist nicht Prüfen, und der Unterschied ist das ganze Sicherheitsmodell
Ein JWT besteht aus drei durch Punkte getrennten Teilen, und die ersten beiden sind schlicht base64url-Text. Wer das Token besitzt, kann Kopf und Nutzlast in einem Schritt lesen — das tut diese Seite — und braucht dafür weder Schlüssel noch Erlaubnis noch Geheimnis. Prüfen ist ein völlig anderer Vorgang: die Signatur über die ersten beiden Teile mit dem Schlüssel des Ausstellers neu berechnen und mit dem dritten vergleichen. Nur die Prüfung sagt Ihnen, dass das Token echt und unverändert ist. Ein Dekoder sagt Ihnen, was ein Token behauptet, nie ob die Behauptung stimmt, denn jeder kann ein Token bauen, das sagt, was ihm gefällt. Beim Debuggen beantwortet Dekodieren Ihre Frage. Bei der Entscheidung, ob Sie einer Anfrage trauen, beantwortet es gar nichts.
Die Nutzlast kann jeder lesen, und das wird ständig vergessen
Das folgt aus dem Vorigen und verdient eine eigene Nennung, denn es ist eine echte Quelle von Datenpreisgabe. Eine JWT-Nutzlast ist kodiert, nicht verschlüsselt. Jeder Claim darin — die Nutzerkennung, die E-Mail-Adresse, die Rolle, der Mandant, welche internen Felder auch immer bequem beizulegen waren — ist für jeden sichtbar, der das Token hat: den Browser, dem es ausgestellt wurde, jede darin laufende Erweiterung und jeden, der es später erlangt. Die Signatur schützt die Nutzlast davor, verändert zu werden, nicht davor, gelesen zu werden. Ein Token ist also ein vernünftiger Ort für eine Kennung und eine Rolle und ein schlechter für eine Anschrift, eine Telefonnummer, einen Lizenzstatus, den jemand peinlich fände, oder anderes, was Sie nicht außen auf einen Umschlag drucken würden. Muss ein Claim privat bleiben, gehört er nicht ins Token.
Lassen Sie das Token nie bestimmen, wie es geprüft wird
Die berühmtesten JWT-Schwachstellen haben dieselbe Gestalt: Eine Bibliothek liest das Feld `alg` aus dem Kopf und vertraut ihm. Die historische Variante ist `alg: none`, die das Token als unsigniert deklariert — ein Prüfer, der das ehrt, nimmt alles an, und ein Angreifer schreibt einfach seine eigene Nutzlast und entfernt die Signatur. Die feinere Variante ist Algorithmusverwechslung: Ein mit HMAC signiertes Token wird einem Server vorgelegt, der RSA erwartet; reicht der Code den öffentlichen RSA-Schlüssel als HMAC-Geheimnis durch und ist dieser Schlüssel veröffentlicht, kann der Angreifer damit Token signieren. Beides wird gleich behoben: Der prüfende Code legt fest, welchen Algorithmus und welchen Schlüssel er akzeptiert, und weist alles andere ab — statt die Antwort aus dem nicht vertrauenswürdigen Teil des geprüften Tokens zu lesen.
Die Zeitstempel sind Sekunden, und nichts erzwingt sie von selbst
Drei Claims bestimmen das Gültigkeitsfenster. `exp` ist der Ablauf, `nbf` der Zeitpunkt, vor dem das Token nicht angenommen werden darf, `iat` der Ausstellungszeitpunkt. Alle drei zählen Sekunden seit der Unix-Epoche, was jeden stolpern lässt, dessen Sprache nativ in Millisekunden rechnet: Das entstandene Token ist entweder längst abgelaufen oder die nächsten fünfzigtausend Jahre gültig, und beide Fehler kommen oft genug vor, um zuerst danach zu sehen. Wichtiger noch: Das sind Behauptungen, keine Durchsetzung. Nichts am Token hört auf zu funktionieren, wenn `exp` verstreicht; Ablauf existiert nur, wenn der prüfende Code ihn mit der aktuellen Zeit vergleicht und die Anfrage abweist. Ein Dekoder, der ein abgelaufenes Token zeigt, nennt die Absicht des Ausstellers, nicht das Verhalten eines bestimmten Servers.
Ein JWT lässt sich nicht widerrufen, und das ist der Handel, den Sie eingegangen sind
Der Grund für diese Token ist zustandslose Prüfung: Ein Server kann die Echtheit einer Anfrage allein mit einem Schlüssel bestätigen, ohne Datenbankabfrage — deshalb skalieren sie über Dienste hinweg. Die direkte Folge: Es gibt nichts zu löschen. Eine in einer Datenbank gespeicherte Sitzung endet in dem Moment, in dem Sie die Zeile entfernen; ein signiertes Token bleibt bis zum Ablauf gültig, gleich was beim Aussteller geschieht, denn niemand fragt den Aussteller. Ein abgeflossenes Token ist deshalb bis zum Ablauf verwendbar — genau darum sollten Zugriffstoken kurz leben, Minuten statt Wochen, begleitet von einem länger lebenden Erneuerungstoken, das widerrufbar ist, weil es *sehr wohl* gegen einen Speicher geprüft wird. Halten Ihre Zugriffstoken einen Monat, haben Sie alle Nachteile der Zustandslosigkeit und keine Sicherheit einer Sitzung.
Warum hier der schärfste Fall für lokales Dekodieren liegt
Fast jedes andere Textwerkzeug behandelt Material, das durch die Umstände heikel ist. Ein JWT ist es per Definition: Es ist das Zugangsdatum, und ein gültiges, nicht abgelaufenes Token genügt, um als die Person zu handeln, der es ausgestellt wurde. Eines in einen gehosteten Dekoder einzufügen sendet ein funktionierendes Authentifizierungsdatum an Dritte, über einen Kanal, der keine Spur hinterlässt — im Tausch gegen das Lesen von Feldern, die Sie lokal hätten lesen können. Hat das Token noch Stunden, kann es der Empfänger nutzen. Diese Seite parst im Browser und überträgt nichts, nachprüfbar im Netzwerk-Tab der Entwicklerwerkzeuge — und wer je ein Produktivtoken auf einer Website eingefügt hat, um dessen Ablauf zu prüfen, behandelt dieses Token richtigerweise als kompromittiert.
Häufige Fehler, die Sie vermeiden sollten
- Ein erfolgreiches Dekodieren für ein gültiges Token halten. Dekodieren braucht keinen Schlüssel und beweist nichts; erst die Signaturprüfung mit dem Schlüssel des Ausstellers belegt Echtheit.
- Private Daten in die Nutzlast legen. Sie ist kodiert, nicht verschlüsselt — die Signatur verhindert Änderung, nicht Lesen, also sieht jeder mit dem Token jeden Claim.
- Das Token den Prüfalgorithmus wählen lassen. `alg` aus dem Kopf zu lesen ist der Mechanismus von `alg: none` und Algorithmusverwechslung; der Prüfer muss Algorithmus und Schlüssel vorab festlegen.
- `exp` in Millisekunden schreiben. JWT-Zeitstempel zählen Sekunden seit der Epoche; ein Millisekundenwert ergibt ein zehntausende Jahre gültiges — oder ein bereits abgelaufenes — Token.
- Ein Produktivtoken in einen gehosteten Dekoder einfügen. Es ist ein aktives Zugangsdatum, das Einfügen hinterlässt keine Spur, und wer es erhält, kann es bis zum Ablauf nutzen.
Im Vergleich
| Kriterium | Dieses Werkzeug | Online-Dekoder | Ein Bibliotheksaufruf |
|---|---|---|---|
| Token an einen Server gesendet | Nie | Meistens ja | Nein |
| Zeitstempel als Datum | Ja | Manchmal | Sie formatieren selbst |
| Sagt klar, dass nicht geprüft wird | Ja | Oft unklar | In der API ausdrücklich |
| Läuft ohne geöffnetes Projekt | Ja | Ja | Nein |
| Konto oder Anmeldung | Nicht nötig | Oft verlangt | Nicht nötig |
| Preis | Kostenlos | Kostenlos / Bezahltarife | Kostenlos |
Funktionen
Vollständige Dreiteilung
Kopf, Nutzlast und Signaturabschnitt getrennt dargestellt, so wie das Format sie definiert.
base64url korrekt behandelt
JWTs nutzen das URL-sichere Alphabet ohne Auffüllung, was ein einfacher Base64-Dekoder falsch macht.
Standard-Claims benannt
`iss`, `sub`, `aud`, `exp`, `nbf`, `iat` und `jti` werden benannt statt als Abkürzung stehen gelassen.
Fehlerhafte Token gemeldet
Ein fehlender Abschnitt oder eine ungültige Kodierung wird gemeldet, statt Teilunsinn zu erzeugen.
Unicode in Claims erhalten
Namen und Werte in Arabisch, Türkisch oder jeder Schrift werden unversehrt dekodiert.
Sofort, ohne Anfrage
Das Parsen geschieht beim Einfügen; nichts wird geladen und nichts gesendet.
Nichts zu installieren
Keine Bibliothek, keine Laufzeitumgebung, keine Abhängigkeiten — es läuft auf der Webseite.
Bereit für Arabisch und RTL
Vollständige Oberfläche in acht Sprachen, darunter Arabisch von rechts nach links.
Standardmäßig sicher
Über HTTPS ausgeliefert, ohne Inhaltsverfolgung und ohne Upload an Dritte.
Wer es nutzt
Entwicklerinnen und Entwickler
Prüfen, warum ein API-Aufruf abgewiesen wird — meist ein abgelaufenes Token oder das falsche Publikum.
Security-Engineering
Claims und Algorithmus eines Tokens ansehen, das in einem Protokoll oder Fehlerbericht auftauchte.
API-Integratoren
Bestätigen, welche Geltungsbereiche und Rollen ein Anbieter tatsächlich ausgestellt hat, bevor Code dagegen entsteht.
Support-Engineering
Ein von Kundenseite geliefertes Token lesen, um Konto und Mandant zu erkennen.
Häufig Gestellte Fragen
Nein. Alles läuft lokal im Browser — Ihr Text wird nie hochgeladen, gespeichert oder geteilt.
Ja — komplett kostenlos, ohne Konto und ohne Limits.