JWT-Parser
Dekodiere und prüfe JSON Web Tokens (JWT) mit Echtzeitvalidierung. Sieh Header-, Payload- und Signaturinformationen sicher in deinem Browser an.
Definition: Ein JSON Web Token besteht aus drei Base64URL-kodierten Teilen — Header, Payload, Signatur — die durch Punkte verbunden sind. Der Header nennt den Signaturalgorithmus, und die Signatur wird gemäß RFC 7519 mit dem Schlüsselmaterial dieses Algorithmus verifiziert.
Header
Payload
Signatur
Algorithmus
Ungültiges Token
So verwenden Sie den JWT-Parser
Token einfügen
Paste your JWT token in the input area
Automatisch dekodieren
Token automatically decodes on paste
Bestandteile prüfen
View header, payload, and signature data
Status prüfen
Prüfen Sie Token-Gültigkeit und Ablaufzeit
JWT-Tokens verstehen
Was ist ein JWT?
Ein JSON Web Token (JWT) ist ein kompaktes, URL-sicheres Mittel zur Darstellung von Claims, die zwischen zwei Parteien übertragen werden. Es besteht aus drei Teilen — Header, Payload und Signatur —, die durch Punkte getrennt und Base64url-kodiert sind.
- • Header: Contains token type and signing algorithm
- • Payload: Contains claims or user data
- • Signature: Verifies token wasn't tampered with
- • Stateless: No server-side session storage needed
Warum JWTs parsen?
Das Parsen von JWTs ist unverzichtbar zum Debuggen von Authentifizierungsproblemen, zum Prüfen von Token-Inhalten, zum Kontrollieren von Ablaufzeiten und zum Verstehen, welche Daten in Token übertragen werden.
- • Debugging: Inspect token contents during development
- • Security: Verify token structure and claims
- • Expiration: Check token validity period
- • Development: Understand authentication flow
Referenz der Standard-JWT-Claims
Registrierte Claim-Namen gemäß RFC 7519, die in fast jeder Token-Payload vorkommen.
| Claim | Vollständiger Name | Bedeutung |
|---|---|---|
| iss | Aussteller | Wer das Token erstellt und signiert hat |
| sub | Betreff | Worum es beim Token geht — in der Regel die Benutzer-ID |
| aud | Empfänger | Für wen das Token bestimmt ist (ein Client oder eine API) |
| exp | Ablauf | Unix-Zeitstempel, nach dem das Token abgelehnt werden muss |
| nbf | Nicht vor | Unix-Zeitstempel, vor dem das Token ungültig ist |
| iat | Ausgestellt am | Unix-Zeitstempel der Erstellung des Tokens |
| jti | JWT-ID | Eindeutige Kennung, nützlich für Sperrlisten |
Häufige JWT-Algorithmen
- • HS256 (HMAC + SHA-256): Symmetrisch — ein gemeinsames Geheimnis signiert und verifiziert. Einfach, aber jeder, der das Geheimnis besitzt, kann Token fälschen.
- • RS256 (RSA + SHA-256): Asymmetrisch — der private Schlüssel signiert, der öffentliche verifiziert. Die Standardwahl für verteilte Systeme.
- • ES256 (ECDSA + SHA-256): Asymmetrisch wie RS256, aber mit deutlich kürzeren Signaturen — eine gute moderne Standardwahl.
- • keine: Unsigniertes Token. Muss von jedem ernsthaften Prüfer abgelehnt werden; historisch die Quelle kritischer Umgehungssicherheitslücken.
Sicherheitshinweise
- • Fügen Sie nie Produktions-Token ein in unbekannte Tools. Dieser Parser läuft vollständig in Ihrem Browser (Prüfung: er funktioniert offline), aber das gilt nicht für jede Website.
- • Ein JWT ist nicht verschlüsselt. Der Payload ist nur base64url-kodiert — jeder, der das Token besitzt, kann es lesen. Speichern Sie niemals Geheimnisse in Claims.
- • Dekodieren ist kein Verifizieren. Eine gültig aussehende Struktur sagt nichts über die Signatur aus. Die Verifizierung erfordert den Schlüssel, der Ihren Auth-Server nie verlässt.
- • Prüfen Sie exp serverseitig. Abgelaufene Token abzulehnen ist die Aufgabe des Verifizierers, nicht des Clients.
Wann Entwickler einen JWT-Parser verwenden
Fehlersuche bei 401- und 403-Antworten
Prüfen Sie, ob das Token tatsächlich die erwarteten Scopes, Rollen oder das Ablaufdatum enthielt, bevor Sie den Server beschuldigen.
OAuth- und OIDC-Tokens untersuchen
Decodieren Sie ein id_token oder access_token und bestätigen Sie, dass iss, aud und sub Ihrer Anwendungskonfiguration entsprechen.
Support und Fehlerbehebung
Prüfen Sie anhand eines Screenshots, welche Claims ein Nutzer tatsächlich erhalten hat — ohne lokale Werkzeuge einzurichten.
Verstehen, wie JWTs funktionieren
Fügen Sie Beispiel-Token ein und sehen Sie, wie Header, Payload und Signatur zusammenwirken.
Sofortige Dekodierung
JWT beim Einfügen automatisch decodieren, mit farbcodierten Abschnitten.
100 % privat
Die gesamte Decodierung erfolgt in Ihrem Browser. Token verlassen Ihr Gerät nie.
Komplett kostenlos
Keine Registrierung, keine Limits. Parsen Sie JWT-Token jederzeit kostenlos.
FAQ zum JWT-Parser
Ist es sicher, einen JWT in dieses Tool einzufügen?
Ja. Das Dekodieren läuft vollständig in Ihrem Browser, ohne Netzwerkaufrufe — Sie können das prüfen, indem Sie die Internetverbindung trennen und die Seite neu laden. Vermeiden Sie trotzdem, Produktions-Tokens irgendwo einzufügen — das gehört zur allgemeinen Sicherheits-Hygiene.
Prüft das Parsen eines JWT dessen Signatur?
Nein. Das Parsen dekodiert nur Header und Payload per base64url. Die Prüfung der Signatur erfordert den Signaturschlüssel (HMAC-Secret oder Public Key), den nur Ihr Auth-Server besitzt.
Warum kann jeder den Payload meines JWT lesen?
JWT-Payloads sind kodiert, nicht verschlüsselt. Jeder, der das Token besitzt, kann es dekodieren und die Claims lesen — das ist beabsichtigt. Speichern Sie niemals Secrets oder sensible Daten in einem JWT-Payload.
Woran erkenne ich, wann ein Token abläuft?
Prüfen Sie den exp-Claim — einen Unix timestamp, ab dem das Token abgelehnt werden muss. Dieser Parser hebt den Token-Status (aktiv, abgelaufen oder noch nicht gültig) automatisch anhand von exp und nbf hervor.
Was ist der Unterschied zwischen HS256 und RS256?
HS256 ist symmetrisch: ein gemeinsames Secret signiert und verifiziert zugleich — jeder, der Token verifizieren kann, kann sie auch fälschen. RS256 ist asymmetrisch: ein privater Schlüssel signiert, ein öffentlicher verifiziert; das ist sicherer, wenn mehrere Dienste Token validieren müssen. Bevorzugen Sie RS256 oder ES256, es sei denn, Sie haben triftige Gründe dagegen.
Mein Token-Header sagt "alg": "none" — ist das ein Problem?
Das bedeutet, dass das Token unsigniert ist. Das ist eine gültige JWT-Struktur, aber ein Verifizierer darf es niemals akzeptieren: Die klassische JWT-Schwachstelle war, dass Angreifer alg auf none setzten, um Signaturprüfungen zu umgehen. Wenn Ihr Backend unsignierte Token akzeptiert, behandeln Sie das als Sicherheitsfehler.
Steigere deine Produktivität mit Tools für Textanalyse und Formatierung