Zum Inhalt springen
Toolars
Erkunden

JWT-Kodierer / Dekodierer

JWT Encoder / Decoder

Dekodiere, signiere und verifiziere JWTs mit HS-, RS- und ES-Algorithmen — Header und Claims als JSON, Schlüssel nur im Arbeitsspeicher.

Lokale Verarbeitung

Verarbeitungsdetails

Tooleingaben werden auf Ihrem Gerät verarbeitet.

Für dieses Tool müssen eventuell Ressourcen geladen werden. Kontodienste laufen separat.

Offline-Nutzung wird vorbereitet…

Datenschutzinformationen
Fehler melden

Aufgabenpfad / von der Eingabe zum Ergebnis

So dekodierst, signierst und verifizierst du ein JWT

  1. 01

    Wähle die Operation

    Wähle Dekodieren, um nicht vertrauenswürdige Claims zu inspizieren, Signieren, um ein Token zu erstellen, oder Verifizieren, um ein Token mit deinem gewählten Algorithmus und Schlüssel zu prüfen.

  2. 02

    Füge das Token ein oder schreibe die Payload

    Für Dekodieren und Verifizieren füge das kompakte dreisegmentige Token in Kompaktes JWT ein, bis zu 64 KiB. Für Signieren schreibe die Claims als JSON-Objekt in JSON-Payload, bis zu 32 KiB; alles, was kein JSON-Objekt ist, wird abgelehnt.

  3. 03

    Lade ein Beispiel zum Erkunden

    Drücke Beispiel laden, um den ganzen Workflow mit sicherem Material zu sehen: Dekodieren bekommt ein lesbares HS256-Token, HMAC-Modi bekommen ein Demonstrationstoken mit seinem Secret, und asymmetrische Modi laden eine Payload, damit du deinen eigenen passenden Schlüssel einfügen kannst.

  4. 04

    Wähle Algorithmus und Schlüssel

    Wähle in Signieren und Verifizieren einen Algorithmus aus den Gruppen HMAC, RSA oder ECDSA. HS-Algorithmen nehmen ein Geteiltes Secret von mindestens 32 UTF-8-Bytes für HS256 (48 für HS384, 64 für HS512); RS und ES nehmen einen PEM-kodierten PKCS8-Private-Key zum Signieren oder einen SPKI-Public-Key zum Verifizieren, bis zu 16 KiB.

  5. 05

    Führe aus und lies das Urteil

    Führe die gewählte Operation aus. Dekodieren zeigt nicht vertrauenswürdige Header- und Payload-Daten; Signieren erzeugt ein kompaktes Token. Verifizieren prüft die Signatur und etwaige exp/nbf-Bedingungen zur angezeigten Browser-Zeit. Lies die Zeitkarten und die spezifische Fehlermeldung, korrigiere dann die Eingabe und führe erneut aus.

  6. 06

    Kopiere, lade herunter und räume auf

    Ergebnis kopieren legt das Token oder das dekodierte JSON in die Zwischenablage, und Herunterladen speichert toolars-jwt.txt oder toolars-jwt.json. Schlüssel bleiben im Arbeitsspeicher: Ein Modus- oder Algorithmuswechsel leert das Schlüsselfeld, Zurücksetzen löscht die aktuellen Eingaben und Schlüssel. Bereits an ein anderes Werkzeug übergebene Ausgaben werden nicht gelöscht; siehe die Datenschutzfrage in den FAQ.

Tool-Fakten

Verarbeitung
In deinem Browser
Eingabe verlässt dieses Gerät
Nie
Aufbewahrung
Optionale lokale Übergabe
Preis
Kostenlos

Deine Eingabe bleibt im Browser.

JWT-Kodierer/Dekodierer nutzt seinen verifizierten lokalen Ausführungspfad und erstellt keinen versteckten Ein- oder Ausgabeverlauf.

Lokale Ausführung

Läuft im aktuellen Browser-Tab.

Keine versteckte Verarbeitung

Aktive Tool-Daten werden nie zu einem Toolars-Dokumentdatensatz.

Kein Konto erforderlich

Nutze den Kern-Workflow ohne Profil. Favoriten werden mit deinem Konto synchronisiert, sobald du dich anmeldest.

Arbeitsbereich und Übergabe

Beim Schließen des Tabs werden normale Arbeitsdaten gelöscht. Bei einer gewählten Übergabe bleibt das Ergebnis auf diesem Gerät auch nach Neuladen oder Schließen des Tabs erhalten und kann 30 Minuten lang übernommen werden. Übernehmen oder Verwerfen entfernt es; abgelaufene Einträge werden bei der nächsten Nutzung der Übergabe bereinigt.

Was JWT-Kodierer/Dekodierer tatsächlich tut

Ein Login-Flow gibt ein Token zurück, das die API immer wieder ablehnt, und die erste Frage ist, was die Claims tatsächlich sagen: Dekodieren zeigt Header und Payload in Sekunden. Später braucht ein Entwicklungsdienst ein kurzlebiges Test-Token, signiert mit einem lokalen Secret, und ein Staging-Schlüssel muss gegen Tokens geprüft werden, die die Verifizierung nicht bestehen. JWT Encoder / Decoder liest, signiert und verifiziert Tokens vollständig im Browser. Produktions-Tokens und Schlüsselmaterial werden in eine Seite eingefügt, die nichts überträgt, und die Schlüssel berühren nicht einmal den Browser-Speicher.

Häufige Fragen

Welche Algorithmen werden unterstützt?
HS256, HS384 und HS512 mit einem geteilten Secret; RS256, RS384 und RS512 mit PKCS8- und SPKI-Schlüsseln; ES256, ES384 und ES512 auf ihren Standardkurven. Ungesicherte alg:none-Tokens sind deaktiviert, und Verifizieren lehnt ein Token ab, dessen Header-Algorithmus vom gewählten abweicht.
Beweist Dekodieren, dass ein Token echt ist?
Nein. Dekodieren liest das Token nur. Selbst ein erfolgreiches Verifizieren-Ergebnis belegt weder die Identität des Ausstellers, die beabsichtigte Zielgruppe, den Widerrufsstatus noch die Berechtigung, das Token in einer Anwendung zu verwenden.
Was sind die Limits und Schlüsselanforderungen?
Tokens bis zu 64 KiB, Payloads bis zu 32 KiB und Schlüssel oder Secrets bis zu 16 KiB. HMAC-Secrets müssen mindestens 32, 48 bzw. 64 UTF-8-Bytes für HS256, HS384 und HS512 haben; RSA- und ECDSA-Schlüssel müssen PEM-kodierte PKCS8-Private-Keys zum Signieren oder SPKI-Public-Keys zum Verifizieren sein.
Was prüft Verifizieren tatsächlich?
Verifizieren nutzt deinen gewählten Algorithmus und Schlüssel, die Browser-Uhr und null Uhr-Toleranz. exp und nbf werden nur geprüft, wenn vorhanden; iat ist kein Alterslimit. Aussteller, Zielgruppe, Schlüsselbesitz, Widerruf und Anwendungsregeln werden nicht geprüft. Dies ist eine Momentaufnahme, keine Autorisierungsentscheidung. HMAC nutzt das exakte UTF-8-Secret, einschließlich Leerzeichen, ohne Base64-Dekodierung.
Warum wird mein Schlüssel oder Secret abgelehnt?
Drei Prüfungen laufen vor jeder Kryptografie: HMAC-Secrets müssen die minimale Bytelänge für den gewählten HS-Algorithmus erreichen, Private Keys müssen PEM-kodierte PKCS8-Werte sein, die mit BEGIN PRIVATE KEY beginnen, und Public Keys müssen SPKI-Werte sein, die mit BEGIN PUBLIC KEY beginnen. Schlüssel über 16 KiB werden abgelehnt, und ein ECDSA-Schlüssel muss auf der Kurve liegen, die sein ES-Algorithmus nennt.
Werden Tokens oder Schlüssel hochgeladen oder gespeichert?
Token und Schlüssel werden lokal ohne Upload verarbeitet. Die Signatur-Engine wird bei Bedarf geladen; Schlüssel bleiben im Komponentenspeicher und werden weder im Browserspeicher noch in Protokollen abgelegt. Zurücksetzen löscht die aktuellen Eingaben und Schlüssel. Wenn du eine Ausgabe ausdrücklich an ein anderes Werkzeug übergibst, wird sie lokal im Browser gespeichert. Zurücksetzen, Neuladen oder Schließen des Arbeitsbereichs löscht diese ausstehende Kopie nicht. Annehmen oder Verwerfen der Übergabe löscht sie; nach 30 Minuten kann sie nicht mehr angenommen werden.

Verwandte Aufgaben statt Sackgasse.

Wechsle in einen anderen fokussierten Arbeitsbereich, ohne zum vollständigen Index zurückzukehren.

URL-Arbeitsbereich

URL Workbench

URL-Listen mit Schutz signierter Links bereinigen; Gründe pro Zeile, Komponentenvergleich und Sitemap-Export.

Bearbeiten

JSON untersuchen

JSON Explorer

JSONPath abfragen, Felder extrahieren und JSON-Pointer-Strukturen verlustfrei zurückwandeln, auch bei großen Zahlen.

Prüfen

JSON Schema prüfen

JSON Schema Validator

Draft 7 oder 2020-12 lokal mit Fehlerpfaden prüfen; Schemas aus mehreren Beispielen ableiten.

Prüfen

HTML veröffentlichen

HTML Publishing

Eingefügtes HTML bereinigen und Listen, Links sowie Tabellensemantik erhalten; Änderungen sicher ansehen.

Veröffentlichen