tooloora

JWT-Decoder – Tokens lokal lesen, Signatur wird NICHT geprüft

JWT-Header und -Payload als lesbares JSON dekodieren, mit exp/iat/nbf als Datum und Abgelaufen-Badge. Läuft komplett im Browser, denn Tokens gehören auf keinen fremden Server.

Läuft lokal — nichts wird hochgeladen

Signatur wird NICHT geprüft

Dieses Tool dekodiert nur. Ob der Token echt und unverändert ist, kann es nicht feststellen – das muss der Server mit dem Schlüssel des Ausstellers prüfen.

Der Token bleibt in deinem Browser – er wird nie an einen Server gesendet.

JWTs lokal dekodieren und lesen

Füge einen JSON Web Token ein und sieh Header und Payload als formatiertes JSON, die Standard-Claims menschenlesbar (exp, iat und nbf als Datum, mit Abgelaufen-Badge) und das Signatur-Segment im Rohformat. Eines vorweg, groß und deutlich: Die Signatur wird NICHT geprüft, dieses Tool dekodiert nur. Alles läuft im Browser, dein Token verlässt dein Gerät nie.

Warum darf ein Token auf keinen fremden Server?

Ein JWT ist kein harmloser Debug-Text, sondern ein lebender Zugangsnachweis: Wer ihn besitzt, kann sich bis zum Ablauf gegenüber der API als der eingetragene Nutzer ausgeben. Einen Produktions-Token in ein Online-Tool zu kopieren, das ihn zum Server überträgt, ist damit dasselbe wie die eigene Session zu verschenken. Genau deshalb dekodiert dieses Tool ausschließlich lokal: kein Request, kein Log, kein Dritter. Es funktioniert auch offline.

Wie ist ein JWT aufgebaut?

Nach RFC 7519 (Mai 2015) besteht ein JWT aus drei Base64url-Segmenten, getrennt durch Punkte: Header (Algorithmus und Typ), Payload (die Claims) und Signatur. Base64url ist eine umkehrbare Kodierung, keine Verschlüsselung, jeder kann Header und Payload ohne Schlüssel lesen. Lege deshalb nie Passwörter oder andere Geheimnisse in Claims ab. Die Signatur macht Manipulation für den Prüfer erkennbar, verbirgt aber nichts.

Was bedeuten die Standard-Claims?

RFC 7519 registriert in Abschnitt 4.1 genau sieben Claims: iss (Aussteller), sub (Subjekt), aud (Ziel-Anwendung), exp (Ablauf), nbf (gültig ab), iat (ausgestellt am) und jti (Token-ID). Die drei Zeit-Claims sind NumericDates, also Sekunden seit der Unix-Epoche (1. Januar 1970 UTC); das Tool rechnet sie in lesbare Daten samt relativer Zeit um und markiert abgelaufene Tokens mit einem Badge.

Warum prüft dieses Tool die Signatur nicht?

Weil eine seriöse Prüfung den geheimen beziehungsweise öffentlichen Schlüssel des Ausstellers braucht und auf den Server gehört, der dem Token vertraut. Ein Decoder im Browser kann nur zeigen, was der Token behauptet, nicht, ob er echt ist. Tools, die im Browser eine Prüfung versprechen, verleiten dazu, den geheimen Schlüssel einzufügen, und der ist noch sensibler als der Token selbst. Fürs Debugging reicht Dekodieren; für Vertrauensentscheidungen niemals.

Wenn der Token nicht dekodierbar ist

Das Tool meldet das betroffene Segment einzeln: Struktur (keine drei Punkte-getrennten Teile), Header oder Payload, jeweils unterschieden nach ungültigem Base64url und ungültigem JSON. Bearer-Präfixe und Zeilenumbrüche aus Log-Kopien werden automatisch entfernt. Bleibt der Fehler, ist die Kopie meist abgeschnitten, oder der Wert ist schlicht kein JWT, sondern ein API-Key oder eine opake Session-ID.

Häufige Fragen

Wird mein Token auf einen Server hochgeladen?

Nein, und bei JWTs ist genau das entscheidend: Ein Token ist ein lebender Zugangsnachweis. Wer ihn besitzt, kann sich bis zum Ablauf gegenüber der ausstellenden API als du ausgeben. Tokens in Online-Tools einzufügen, die sie an einen Server übertragen, heißt praktisch, die eigene Session zu verschenken. Dieser Decoder läuft komplett in deinem Browser, sendet nichts und funktioniert offline.

Prüft dieses Tool die Signatur?

Nein, absichtlich nicht, und es sagt das deutlich: Das Signatur-Segment wird angezeigt, aber nie geprüft. Dekodieren zeigt nur, was der Token behauptet, nicht, dass er echt oder unverändert ist. Die Prüfung braucht den geheimen oder öffentlichen Schlüssel des Ausstellers und gehört auf den Server, der dem Token vertraut. Behandle einen dekodierten Token nie als verifiziert.

Warum kann jeder meinen JWT ohne Schlüssel lesen?

Weil JWTs kodiert sind, nicht verschlüsselt. Nach RFC 7519 sind Header und Payload schlichtes Base64url-kodiertes JSON, eine umkehrbare Transport-Kodierung, die jeder rückgängig machen kann. Die Signatur schützt die Integrität, Manipulation fällt dem Prüfer also auf, aber sie verbirgt den Inhalt nicht. Lege deshalb nie Geheimnisse wie Passwörter in JWT-Claims ab.

Was bedeuten exp, iat, nbf, iss, sub und aud?

Das sind sechs der sieben registrierten Claims aus RFC 7519 Abschnitt 4.1 (der siebte ist jti, die Token-ID). exp ist die Ablaufzeit, iat der Ausstellungszeitpunkt, nbf der Moment, vor dem der Token nicht akzeptiert werden darf; alle drei sind NumericDates, Sekunden seit der Unix-Epoche, die dieses Tool in lesbare Daten umrechnet. iss benennt den Aussteller, sub das Subjekt und aud die Ziel-Anwendung.

Das Tool meldet, mein Token sei kaputt. Was nun?

Die Fehlermeldung benennt das betroffene Segment. Ein JWT muss aus drei Base64url-Teilen bestehen, getrennt durch Punkte: Header.Payload.Signatur. Häufige Ursachen sind abgeschnittene Kopien aus Logs, Zeilenumbrüche im Token (dieses Tool entfernt Whitespace automatisch), ein fehlendes Segment oder ein API-Key bzw. eine opake Session-ID, die schlicht kein JWT ist.

Verwandte Tools

Base64 kodieren & dekodieren — lokal, UTF-8-sicherBase64 kodieren und dekodieren (inkl. URL-sicher), UTF-8-korrekt, 100% im Browser.JSON-Formatter & Validator – lokal, mit FehlerpositionJSON formatieren, minifizieren und validieren, mit exakter Fehlerposition, 100% im Browser.Hash-Generator — SHA-256, SHA-512 & mehr, lokalSHA-1/256/384/512-Prüfsummen von Text via Web Crypto, live, 100% im Browser.