🔑 JWT-Decoder ☆

Überblick

JWT-Decoder dekodiert jedes JSON Web Token direkt im Browser. Fügen Sie ein Token ein und sehen Sie sofort die drei Teile: Header (Algorithmus, Typ, Key-ID), Payload (alle Claims als formatiertes JSON) und die rohe Signatur. Zeit-Claims werden in lesbare Daten übersetzt, und das Tool zeigt, ob das Token gültig, abgelaufen, noch nicht gültig ist oder kein Ablaufdatum hat. Alles läuft clientseitig, Ihr Token wird nie hochgeladen, was wichtig ist, da JWTs oft Sitzungs-IDs und persönliche Daten enthalten. Dekodieren prüft die Signatur nicht.

Was ein JWT enthält

Ein JWT besteht aus drei base64url-Segmenten, getrennt durch Punkte. Der Header nennt Signaturalgorithmus und Key-ID; die Payload trägt Claims wie iss (Aussteller), sub (Subjekt), aud (Audience), exp (Ablauf), iat (Ausgestellt) und nbf (Nicht vor); die Signatur erlaubt Servern, Aussteller und Integrität zu prüfen. Der Decoder zeigt alle drei, formatiert das JSON, humanisiert Zeitangaben und meldet, ob das Token gültig, abgelaufen oder noch nicht aktiv ist.

Spezifikationen und Kompatibilität

Eigenschaft	Verhalten
Eingabe	Jedes JWS-Token (header.payload.signature)
Dekodierte Teile	Header, Payload-Claims und Rohsignatur
Zeit-Claims	exp, iat, nbf als lesbare Daten mit Status
Status	Gültig, abgelaufen, noch nicht gültig oder ohne Ablauf
Signatur	Nicht verifiziert: nur Dekodierung
Verarbeitung	100 % clientseitig; Tokens nie hochgeladen
Kosten	Kostenlos, kein Konto, unbegrenzte Tokens

Datenschutz: Session-Tokens bleiben im Browser

Ein JWT ist meist eine aktive Credential. Sie in einen Online-Decoder zu geben, übergäbe eine laufende Sitzung. Alles wird lokal dekodiert: nichts übertragen oder gespeichert. Auch die Ausgabe als sensibel behandeln.

JWTs sicher debuggen

• Zuerst exp prüfen, meist ist es simple Ablauffrist.
• iat und nbf bei Uhrendrift vergleichen.
• Prüfen, ob aud und iss zur API passen.
• alg: none und symmetrische Verfahren brauchen strenge Servervalidierung.
• Produktions-Tokens nie in unkontrollierte Tools einfügen.

Mehr: Entwicklerwerkzeuge für Base64, Hashing und Regex.

JWT-Struktur, Signaturen und häufige Fehler

Ein JSON Web Token hat drei durch Punkte getrennte Teile: einen Header, der den Algorithmus beschreibt, eine Payload mit den Claims und eine Signatur, mit der der Empfänger prüft, dass die ersten beiden unverändert sind. Alle drei sind Base64URL-kodiert, Kodierung, keine Verschlüsselung: Wer das Token hat, kann die Claims lesen, also gehört nichts Sensibles in die Payload. Dekodieren ist lokal also immer sicher, während Verifizieren den Secret- oder Public-Key erfordert und serverseitig geschehen muss. Mehrere Fehler wiederholen sich in echten Systemen. Der alg:none-Angriff nutzt Bibliotheken, die dem Header vertrauten und ein unsigniertes Token akzeptierten; eine korrekte Implementierung legt den erwarteten Algorithmus fest und lehnt alles andere ab. HS256, ein symmetrischer Algorithmus, mit schwachem oder geleaktem Secret ist ein weiterer: Das Secret muss lang und zufällig sein, und asymmetrische Verfahren wie RS256 sind vorzuziehen, wenn viele verifizieren, aber nur einer signieren darf. Die Claim-Prüfung wird leicht vergessen: exp und nbf müssen gegen die aktuelle Zeit geprüft werden, iss und aud müssen den Erwartungen entsprechen, und jti ermöglicht Widerruf bei Diebstahl. Tokens sind Bearer-Credentials, gehören also nur über HTTPS und sollten dort gespeichert werden, wo Skripte sie bei XSS nicht lesen können. Denken Sie daran: Ein dekodiertes Token beweist nichts, solange die Signatur nicht verifiziert ist. Dieses Tool dekodiert lokal und speichert nichts.