Vergleich · Aktualisiert 2026-05-05

TaskKit's JWT-Tools vs jwt.io

Beide Tools decodieren und verifizieren JSON Web Tokens vollständig im Browser. Die praktischen Unterschiede liegen darin, was jedes Tool neben dem Editor lädt, wie es sich bei einer langsamen oder feindseligen Signatur verhält, und einer Handvoll Features, die das eine hat und das andere nicht. Die Zusammenfassung unten ist gemessen; der Rest der Seite zeigt das vollständige Bild.

Privacy, gemessen

Beide Tools behaupten, ihre Arbeit im Browser zu erledigen. Diese Behauptung ist nur dann etwas wert, wenn man sie überprüfen kann. Jede Seite unten wurde am 2026-05-05 in einem frischen Chrome-Profil mit gelöschtem Cache geladen, und jede ausgehende Netzwerkanfrage wurde gezählt, bevor ein einziges Zeichen getippt wurde. Derselbe Test läuft gegen TaskKit's JWT-Decoder.

Jeder dieser Aufrufe feuert, bevor du einen Token einfügst. Keiner ist nötig, damit die Seite einen JWT decodiert — es sind Analytics, Tag Management und Consent-Flow-Infrastruktur. TaskKit liefert nichts davon aus. Mehr dazu, wie TaskKit mit deinen Daten umgeht.

Feature-Matrix

Beide Tools decken im Wesentlichen die gesamte JWT-Spec ab. Unten siehst du, was jedes Tool heute akzeptiert, gruppiert nach Kategorie.

Runtime Safety

WebCrypto's verify ist auf wohlgeformten Signaturen schnell. Auf feindlichem Input nicht. Pathologische RSA-Exponenten, übergroße Schlüssel, fehlerhafte Ed25519-Signaturen oder eine bösartig gebaute JWKS können den Verifier lange genug festhalten, um den Tab einzufrieren — ein reales Risiko, wenn der Token vor dir aus einer nicht vertrauenswürdigen Quelle stammt.

TaskKit führt die Signatur-Verifikation in einem dedizierten Web Worker mit 2-Sekunden-Wall-Clock-Timeout aus. Überschreitet der Worker das Budget, wird er beendet und die Seite zeigt einen Fehler statt zu hängen. jwt.io verifiziert auf dem Main Thread, eine langsame Signatur ist also eine langsame Seite. Dieselbe Architektur schützt TaskKit's Regex-Tester (gegen (a+)+b-artiges Backtracking) und den JSON-Formatter (gegen mehrere Megabyte große Parses).

Editor-Details, die im Alltag zählen

• Dreifarbige Hervorhebung im Input. Beide Tools kolorieren die drei Token-Segmente, jwt.io aber nur in einem read-only-«Decoded»-Pane. TaskKit färbt die Segmente in der Textarea, in der du tatsächlich bearbeitest, was es einfacher macht, einen falsch eingefügten Punkt zu entdecken.
• Stets sichtbare Claim-Labels. jwt.io's Klartext-Claim-Namen (iat → "Issued at") liegen hinter einem «Claims Breakdown»-Tab. TaskKit zeigt sie inline unter dem Payload, sodass die Daten und Beschreibungen mit einem Blick sichtbar sind.
• Ehrliches x5c-Handling. Wird der x5c-Header eines Tokens zur Verifikation genutzt, zeigt TaskKit's Result-Chip «verified with the x5c certificate from the token header (chain not validated)», statt End-to-End-Vertrauen zu suggerieren. Die Validierung der Kette zurück zu einer Zertifizierungsstelle würde das Holen von CA-Roots erfordern und liegt außerhalb des Scopes eines reinen Browser-Tools.
• HMAC-base64url-Toggle. Manche HMAC-Schlüssel werden als base64url-codierte Bytes gespeichert (zum Beispiel ein JWKS oct-Key mit einem k-Feld). Ein kleiner Toggle neben dem Algorithmus-Chip schaltet die Secret-Eingabe zwischen Literal-String und base64url-Bytes-Interpretation um, sodass du nicht selbst decodieren musst.
• EdDSA-Roh-Schlüssel-Eingabe. Füg einen Ed25519-Key als 64 Hex-Zeichen, 43 base64url-Zeichen, JWK oder PEM ein. jwt.io erwartet nur PEM oder JWK.

Wo jwt.io stärker ist

Ein nützlicher Vergleich ist kein einseitiger Pitch. Drei Dinge macht jwt.io heute klar besser:

• Libraries-Verzeichnis. Ein kuratierter, durchsuchbarer Index von JWT-Libraries nach Sprache. Wenn du eine Implementation für einen Service suchst, ist jwt.io's Verzeichnis die richtige Adresse.
• Ausführliche Introduction. Eine kanonische «Was ist ein JWT»-Seite, die das Konzept tief genug erklärt, um es end-to-end zu vermitteln. TaskKit's Erklärtext unter dem Decoder ist kürzer und tool-fokussiert.
• Per-Claim-RFC-Links. Jeder registrierte Claim verlinkt in den entsprechenden Abschnitt des RFC, der ihn definiert. Eine Kleinigkeit, aber nützlich, wenn du Spec-Konformität prüfst.

Was TaskKit bewusst weglässt

Eine Privacy-Garantie ist einfacher zu halten, wenn keine Hintertüren eingebaut sind. Ein paar Features, die andere Tools bieten, fehlen hier bewusst.

• OIDC-Auto-Discovery. Manche Tools lassen dich eine Issuer-URL einfügen und holen dann still .well-known/openid-configuration für die Schlüssel. Das ist eine ausgehende Anfrage von deinem Browser an einen Drittanbieter — und die URL selbst kann Deployment-Details verraten. TaskKit verlangt, dass du die JWKS selbst einfügst.
• JWKS-per-URL-Feld. Dieselbe Begründung. Ein einzeiliges curl in deiner Terminal schlägt einen Outbound-Fetch von der Seite, die du gerade debuggst.
• Analytics standardmäßig. Die Codebase unterstützt einen optionalen, privacy-erhaltenden Cloudflare-Web-Analytics-Token, der aber aus bleibt, sofern der Betreiber ihn nicht explizit aktiviert. Die gehostete Version auf taskkit.net hat ihn ebenfalls aus.
• Konten und serverseitige Historie. Speichern und Teilen passieren via URL-Fragmente, wo unterstützt. Nichts wird auf einem Server abgelegt, weil es keinen Server gibt.

TaskKit's JWT-Tools ausprobieren

Methodik

Getestet am 2026-05-05 in Chrome mit gelöschtem Cache und First-Party-Cookies. Netzwerkanfragen wurden vom Seitenaufruf bis zum ersten Tastendruck gezählt. Die Feature-Matrix spiegelt das Verhalten beider Tools an diesem Datum wider und wird neu geprüft, sobald eines der Tools eine wesentliche Änderung ausliefert.

jwt.io ist eine Marke des jeweiligen Inhabers. Diese Seite steht in keiner Verbindung zu jwt.io und wird nicht von jwt.io unterstützt.