Auf dieser Seite

Warum Sie JWTs nicht in jwt.io einfügen sollten (und was Sie stattdessen verwenden sollten)

Ein Produktions-Token landet in Ihrem Terminal. Sie müssen schnell wissen, wer ihn ausgestellt hat, wann er abläuft und welche Claims er enthält. Also tun Sie das, was die meisten Entwicklerinnen und Entwickler tun: Sie öffnen jwt.io, fügen den Token ein und lesen den dekodierten Payload.

Halt. Dieser JWT ist eine Anmeldeinformation. Die Seite, in die Sie ihn gerade eingefügt haben, wird von Dritten betrieben, mit einer Vergangenheit von stillschweigend hinzugefügtem Analytics und einer laufenden Neuentwicklung, die durch die Datenschutzbedenken der eigenen Maintainer ausgelöst wurde. Es gibt eine bessere Antwort, und die Suchanfrage, weshalb Sie wahrscheinlich hier sind — „jwt.io Alternative Datenschutz” — hat eine echte Lösung.

Dieser Leitfaden geht das tatsächliche Bedrohungsmodell durch, was das jwt.io-Team selbst öffentlich eingeräumt hat und wie Sie verifizieren, dass ein JWT-Debugger Ihren Token niemals irgendwohin sendet. Wenn Sie die Erklärung überspringen und gleich einen Token im Browser dekodieren möchten: Der JWT Decoder läuft vollständig clientseitig — öffnen Sie ihn, trennen Sie die Internetverbindung und beobachten Sie, dass er weiterhin funktioniert.

TL;DR: Ist jwt.io sicher?

Kurze Antwort: Die Startseite von jwt.io warnt selbst davor. Der eigene Warnhinweis lautet im Wesentlichen: „JWTs sind Anmeldeinformationen — seien Sie vorsichtig, wo Sie sie einfügen.” Diese Warnung ist korrekt, und sie gilt für jwt.io ebenso wie für jedes andere Online-Tool.

Für nicht sensible Demo-Tokens ist jwt.io in Ordnung. Für alles aus einer realen Umgebung — Produktion, Staging, Sandbox, Partner-Integration — gilt die sicherere Standardannahme: lokal dekodieren. Der Rest dieses Artikels erklärt das Warum und das Wie.

Was tatsächlich passiert, wenn Sie einen JWT in einen Online-Decoder einfügen

Ein JWT (JSON Web Token) besteht aus drei mit Punkten verbundenen Base64URL-kodierten Segmenten: einem Header, einem Payload und einer Signatur. Header und Payload sind nicht verschlüsselt; sie sind lediglich kodiert. Wer den Token besitzt, kann seinen Inhalt lesen — einschließlich jedes Dienstes, der ihn empfängt, selbst wenn nur, um ihn „clientseitig zu dekodieren”.

Zwischen dem Drücken von Cmd-V und dem Anzeigen der dekodierten Claims können mehrere Dinge passieren:

  • Browserverlauf. Viele Tools übergaben den Token historisch im URL-Query-String, wodurch er im Browserverlauf, in Referrern übergeordneter Tabs und in jedem synchronisierten Verlaufs-Backend (Chrome Sync, Firefox Sync, Edge-Profile) landet.
  • Serverlogs. Selbst Seiten, die in JavaScript dekodieren, stellen weiterhin Anfragen für Analytics, Schriften und Werbeskripte. Wenn der Token in der URL steht, erscheint er in Referer-Headern, die an diese Drittanbieter gesendet werden.
  • Telemetry-SDKs. Bis September 2019 sandte jwt.io Metriken von der Seite, obwohl sie nur clientseitigen Betrieb bewarb, wie der Ingenieur Jamie Tanna dokumentierte (Capital One Open Banking). „Clientseitig” ist eine Behauptung, kein Audit.
  • Künftige Code-Änderungen. Eine Seite, die heute clientseitig ist, kann morgen eine serverseitige Änderung ausliefern. Ein vielzitierter Hacker-News-Kommentator formulierte es so: „Wenn Sie es sich zur Gewohnheit machen, diese Tools zu nutzen, wird eines davon irgendwann kompromittiert. Sei es durch einen technischen Hack, finanziellen Druck, den Kauf durch ein unmoralisches Unternehmen oder einen verärgerten Mitarbeiter irgendwo auf dem Weg.”

Nichts davon erfordert böse Absicht. Es erfordert nur, dass irgendjemand, irgendwo zwischen Ihrer Tastatur und Ihren Augen, eine Kopie Ihres Tokens lange genug besitzt, um sie zu missbrauchen.

Das echte Bedrohungsmodell

Der erste Einwand lautet immer gleich: „Aber der Token läuft in 15 Minuten ab — was kann schon Schlimmes passieren?” Tatsächlich einiges.

Replay innerhalb des Gültigkeitsfensters. Fünfzehn Minuten reichen einem Skript, das eine Analytics-Pipeline überwacht, einer geleakten Logdatei oder einem Referrer-Header locker, um den Token zu greifen und Ihre API als Sie aufzurufen. Handelt es sich um einen Refresh-Token (der Tage oder Wochen gültig sein kann), ist das Fenster deutlich größer.

Claims sind eine Schatzkarte. Ein typischer Payload enthält die Benutzer-ID (sub), Tenant-ID, Rollenliste, Audience (aud), Issuer (iss) und oft Custom Claims wie E-Mail, interne Flags oder Feature-Berechtigungen. Selbst ein abgelaufener JWT verrät einem Angreifer genau, welchen Benutzer er anvisieren, welche API er ansprechen muss und wie eine Privilegieneskalation in Ihrem Unternehmen aussieht.

Nicht-Prod-Tokens leaken produktionsähnliche Geheimnisse. Open-Banking-Sandbox-JWTs und Partner-Integrations-Tokens enthalten häufig Zertifikat-Fingerprints, Key-IDs und Audience-URLs, die direkt auf Produktions-Infrastruktur abbilden. Jamie Tanna beschrieb, sich „mehrfach die Finger verbrannt zu haben”, als Kollegen Nicht-Produktions-JWTs und Open-Banking-Sandbox-Zertifikate in jwt.io einfügten.

Compliance-Folgen sind unabhängig vom Schaden. Wenn Ihr Unternehmen unter SOC 2, ISO 27001, PCI-DSS oder eine HIPAA-nahe Regelung fällt, ist das Einfügen einer Anmeldeinformation in einen Drittanbieterdienst meldepflichtig, unabhängig davon, ob tatsächlich etwas ausgenutzt wurde. Der Audit-Befund ist der Vorfall.

JWT-Handling-Bugs werden weiterhin ausgeliefert. CVE-2026-29000, ein Authentifizierungs-Bypass im JwtAuthenticator von pac4j, wurde Anfang dieses Jahres bekanntgegeben. Token-Validierungs-Bugs sind kein Problem von 2018; das Debuggen von JWTs ist genau die Situation, in der Entwickler zu Online-Tools greifen — und genau dann sind geleakte Tokens für einen Angreifer, der dieselbe Library beobachtet, am wertvollsten.

Was die jwt.io-Maintainer selbst gesagt haben

Das stärkste Argument gegen das Einfügen von Tokens in jwt.io kommt von jwt.io selbst.

In GitHub Issue #700, „The Future of JWT.io”, eröffnet am 19. Juli 2024, schrieb ein Okta/Auth0-DevRel-Engineer wörtlich, dass „die Übergabe eines Tokens an die Seite über URL-Query-Parameter Bedenken hinsichtlich der Privatsphäre des Tokens hervorgerufen hat”. Das Issue legt eine geplante Neuentwicklung dar, die von URL-Query-Parametern auf URL-Fragmente wechselt, Decode/Encode/Verify in separate Widgets aufteilt und das automatische Laden von Tokens aus der URL beim Seitenaufruf einstellt.

Das ist das Team, das jwt.io betreibt, das öffentlich eine Neugestaltung zusagt, weil das bestehende Handling nicht privat genug ist. Zum Zeitpunkt dieses Artikels wurden Teile des Redesigns ausgeliefert, andere nicht. Der genaue Status ist für Sie irrelevant: Der Punkt ist, dass die eigene Datenschutz-Messlatte des Betreibers höher liegt als die der Legacy-Seite, und Sie haben keine zuverlässige Möglichkeit zu wissen, welche Version ein Besucher an einem beliebigen Tag tatsächlich nutzt.

Daneben fand PentesterLabs The State of JWT Libraries on JWT.io (28. März 2025), dass die kuratierte Library-Liste von jwt.io weiterhin Repositories empfiehlt, die 2018 archiviert wurden, Libraries, die zuletzt 2015 aktualisiert wurden, und mindestens eine Implementierung, die HMAC-MD5 unterstützt (einen Algorithmus, der in der JWT-Spezifikation gar nicht existiert). Eine Library auf der Liste extrahiert den alg-Wert per Regex statt JSON zu parsen; eine andere signiert mit „einer zufälligen Zeichenkette zufälliger Länge und dem Payload als Geheimnis”. Louis Nyffenegger, Gründer von PentesterLab, fasst zusammen: „Entwickler wählen möglicherweise unwissentlich unsichere oder verlassene Libraries.”

Der Library-Katalog ist nicht dasselbe Problem wie die Token-Privatsphäre, aber er weist in dieselbe Richtung: Die Eigenschaft „beliebt und bequem” leistet in Ihrem Vertrauensmodell sehr viel ungerechtfertigte Arbeit.

Was „Client-seitiger JWT-Decoder” tatsächlich bedeutet

Ein wirklich clientseitiger Decoder tut drei Dinge:

  1. Lädt den Code einmal über HTTPS und läuft dann vollständig in Ihrem Browser-Tab.
  2. Führt die Dekodierung in JavaScript mit atob() (oder einem Base64URL-Helfer) und JSON.parse() auf den Header- und Payload-Segmenten durch.
  3. Verifiziert optional Signaturen mit der Web Crypto API, demselben auditierten Primitiv, das Ihre TLS-Handshakes absichert.

Kein fetch, kein XHR, kein navigator.sendBeacon, kein Analytics-Ping mit dem Token. Die Token-Bytes verlassen niemals den Speicher des Tabs.

Das ist nicht die Standardannahme. Das ist eine Eigenschaft, die ein Tool entweder hat oder nicht hat — und die Sie selbst in unter einer Minute überprüfen können.

So verifizieren Sie, dass ein JWT-Tool wirklich clientseitig ist (60-Sekunden-Rezept)

Das ist die mit Abstand nützlichste Fähigkeit in diesem Artikel. Wenden Sie sie auf jedes Tool an, das Anmeldeinformationen verarbeitet — auch auf das von remove.sh.

Methode 1: Der Flugmodus-Test

  1. Öffnen Sie das Tool in einem neuen Tab.
  2. Warten Sie, bis die Seite vollständig geladen ist.
  3. Deaktivieren Sie WLAN oder aktivieren Sie den Flugmodus.
  4. Fügen Sie einen Token ein und dekodieren Sie ihn.

Erscheinen die dekodierten Header- und Payload-Inhalte, erledigt das Tool die Arbeit lokal. Sehen Sie einen Spinner oder einen Fehler, ruft das Tool den Server auf — wahrscheinlich mit Ihrem Token im Request-Body. Das ist die schnellste und eindeutigste Prüfung.

Methode 2: Der Netzwerk-Audit in den DevTools

  1. Öffnen Sie die DevTools (F12 oder Cmd+Option+I).
  2. Wechseln Sie zum Network-Tab.
  3. Filtern Sie nach Fetch/XHR.
  4. Klicken Sie auf Clear (das Verbots-Symbol) und fügen Sie dann Ihren Token ein.

Ein clientseitiger Decoder zeigt während des Dekodierens null Fetch/XHR-Anfragen. Erscheint eine Anfrage, klicken Sie sie an und prüfen Sie den Payload-Tab — Ihr Token könnte im Request-Body oder Query-String stehen. Selbst wenn nicht, kontaktiert das Tool bei jedem Tastendruck das Netzwerk, was ausreicht, um es für sensible Arbeit zu disqualifizieren.

Methode 3: Lesen Sie die Adressleiste

Setzt das Tool den Token direkt in die URL — ?token=eyJhbG... — steht dieser Token nun in Ihrem Browserverlauf, in Ihrer Shell-History, falls Sie die URL kopiert haben, im Referer-Header, der an jedes Analytics-Skript der nächsten besuchten Seite geschickt wird, und in jedem von Ihnen genutzten Clipboard-Manager. Tools, die URL-Fragmente (#token=...) verwenden, sind besser, weil Fragmente nicht an Server gesendet werden — Query-Parameter sind dagegen ein sofortiges Ausschlusskriterium.

Probieren Sie es selbst aus: Öffnen Sie den JWT Decoder auf remove.sh und führen Sie alle drei Prüfungen durch. Das Network-Panel bleibt nach dem Seitenaufruf leer, die URL enthält niemals Ihren Token, und die Seite funktioniert im Flugzeug. Das ist eine überprüfbare Eigenschaft, kein Marketingversprechen.

Eine datenschutzfreundliche jwt.io-Alternative: Im Browser dekodieren

Wenn Sie bis hierhin gelesen haben, ist die Empfehlung wenig überraschend: Verwenden Sie einen Decoder, den Sie verifizieren können — und verifizieren Sie ihn auch.

Der JWT Decoder von remove.sh basiert auf denselben Primitiven, die dieser Artikel beschreibt. Er nutzt atob() für die Base64URL-Segmente, JSON.parse() für Header und Payload und die Web Crypto API für die HMAC-Signaturverifikation (HS256/HS384/HS512). Tokens werden niemals in die URL serialisiert. Es gibt kein Analytics-SDK, das das Eingabefeld liest. Das Tool meldet den Ablaufstatus durch Vergleich des exp-Claims mit Ihrer lokalen Uhr und beschriftet registrierte Claims (iss, sub, aud, iat, nbf, jti), damit Sie sie nicht auswendig kennen müssen.

Was es heute nicht tut, ist die Verifizierung von RSA- oder ECDSA-Signaturen (RS256/ES256). Für asymmetrische Signaturen haben Sie zwei vernünftige Optionen, die im nächsten Abschnitt beschrieben werden.

Ist Ihr Token in Authorization: Bearer eyJhbG... verpackt, fügen Sie das Ganze ein — der Decoder entfernt das Bearer -Präfix automatisch. Haben Sie nur die Base64-kodierten Segmente und möchten sie roh inspizieren, dekodiert der Base64-Encoder & -Decoder einzelne Segmente, ohne zu versuchen, sie als JWT zu interpretieren — nützlich, wenn Sie einen fehlerhaften Token vermuten.

Signaturen verifizieren, ohne Ihr Geheimnis preiszugeben

Das Dekodieren sagt Ihnen, was ein Token behauptet. Die Verifizierung sagt Ihnen, ob Sie ihm vertrauen können. Beides sind nicht dieselbe Operation, und sie haben unterschiedliche Datenschutzimplikationen.

HMAC (HS256/HS384/HS512)

Die HMAC-Verifizierung benötigt das geteilte Geheimnis. Das ist der gefährliche Fall: Ein geleaktes Geheimnis bedeutet, dass jeder gültige Tokens für Ihren Dienst ausstellen kann. Fügen Sie ein HMAC-Geheimnis niemals in ein Online-Tool ein, dessen Lokalität Sie nicht verifizieren können.

Der JWT Decoder von remove.sh verifiziert HMAC-Signaturen mit der Web Crypto API. Das Geheimnis bleibt im Speicher Ihres Tabs und wird niemals ins Netzwerk serialisiert. Sie können das bestätigen, indem Sie den Flugmodus-Test mit ausgefülltem Token und Geheimnis durchführen — die Verifizierung wird dennoch abgeschlossen.

Wollen Sie eine stärkere Garantie als selbst einen auditierten Browser-Tab, greifen Sie zum lokalen openssl-Rezept weiter unten, um den HMAC aus dem Header-Payload-Teil neu zu berechnen und ihn selbst mit dem Signatur-Segment zu vergleichen.

RSA / ECDSA (RS256, RS384, RS512, ES256, ES384, ES512)

Asymmetrische Verifizierung benötigt nur einen öffentlichen Schlüssel, der per Definition nicht geheim ist. Das ist der einfache Fall für Online-Tools — die durchfließenden Daten sind für sich genommen nicht sensibel. Schützen müssen Sie nur den Token, der unabhängig vom Algorithmus dieselben Claims enthält.

Bis remove.sh die RSA/ECDSA-Verifizierung im Decoder ausliefert, ist die sauberste lokale Option step crypto:

step crypto jwt verify \
  --jwks https://your-issuer.example.com/.well-known/jwks.json \
  --iss https://your-issuer.example.com \
  --aud your-audience < token.txt

Oder mit openssl und einem PEM-formatierten öffentlichen Schlüssel:

# Extract the signed portion (header.payload)
SIGNED=$(cut -d. -f1,2 token.txt)

# Extract the signature, decode Base64URL
cut -d. -f3 token.txt | tr '_-' '/+' | base64 -d > sig.bin

# Verify with openssl
echo -n "$SIGNED" | openssl dgst -sha256 -verify pubkey.pem -signature sig.bin

Beide funktionieren offline. Beide ermöglichen es Ihnen, einen Token zu verifizieren, ohne ihn jemals in eine Website einzufügen.

Einen JWT lokal mit der CLI dekodieren

Für einmalige Inspektionen abseits des Browsers reichen zwei Einzeiler für die meisten Fälle.

Header hübsch ausgeben:

cut -d. -f1 token.txt | tr '_-' '/+' | base64 -d 2>/dev/null | jq .

Payload hübsch ausgeben:

cut -d. -f2 token.txt | tr '_-' '/+' | base64 -d 2>/dev/null | jq .

Der Schritt tr '_-' '/+' wandelt Base64URL in Standard-Base64 um, was die meisten Decoder erwarten. Das 2>/dev/null schluckt die base64: invalid input-Warnung, die erscheint, wenn das Segment nicht aufgefüllt ist — jq gibt das JSON dennoch korrekt aus.

Falls Sie kein jq haben, formatiert der JSON-Formatter auf remove.sh die Ausgabe beider Befehle im Browser, ohne sie irgendwohin zu senden. Leiten Sie die Ausgabe per pbcopy (macOS) oder xclip -sel clip (Linux) in die Zwischenablage und fügen Sie sie ein.

So teilen Sie einen JWT sicher in einem Bug-Report

Ein häufiger Grund, weshalb Entwickler zu jwt.io greifen, ist nicht das Debuggen — sondern das Einfügen eines dekodierten Payloads in einen Slack-Thread oder ein Ticket, damit ein Teammitglied die Claims sehen kann. Dafür gibt es ein sichereres Vorgehen.

  1. Dekodieren Sie den Token lokal mit einer der oben genannten Methoden.
  2. Kopieren Sie nur das dekodierte JSON — niemals die kodierte eyJhbG...-Form. Die kodierte Form ist die Anmeldeinformation; das dekodierte JSON sind nur Daten.
  3. Schwärzen Sie identifizierende Claims vor dem Teilen: Ersetzen Sie sub, email, name, Custom-User-IDs und Tenant-IDs durch Platzhalterwerte (sub: "user-redacted").
  4. Lassen Sie das Signatur-Segment weg. Ohne Geheimnis oder privaten Schlüssel lässt es sich aus Header und Payload nicht rekonstruieren — das geschwärzte JSON ist also keine nutzbare Anmeldeinformation mehr.
  5. Für Test-Fixtures generieren Sie einen frischen Token, signiert mit einem Wegwerf-Geheimnis. Für die Reproduktion eines Bugs zählt die Form, nicht die Werte.

Muss ein Teammitglied bestätigen „ja, das ist derselbe Token, den ich hier sehe”, ohne dass einer von Ihnen den Token selbst teilt, fügen Sie den kodierten JWT in den Hash-Generator auf remove.sh ein und tauschen stattdessen den SHA-256-Fingerabdruck aus. Gleicher Fingerabdruck bedeutet gleicher Token; der Fingerabdruck verrät nichts über Claims oder Signatur.

Dieses Vorgehen verwandelt einen Anmeldeinformations-Austausch in einen Datenaustausch — und das ist es, was Ihre Sicherheitsrichtlinie eigentlich will.

Häufig gestellte Fragen

Ist jwt.io Open Source?

Der Frontend-Code der Seite ist auf GitHub veröffentlicht, aber „Open Source” sagt Ihnen nicht, was heute auf jwt.io tatsächlich läuft. Wie Jamie Tanna anmerkte: „Wir haben keine Ahnung, ob der Quellcode … auf der Live-Seite überhaupt verwendet wird.” Überprüfbarkeit — ein Network-Tab, der leer bleibt — ist ein stärkeres Signal als ein öffentliches Repo.

Hat jwt.io jemals Tokens geleakt?

Es gibt keine öffentliche Bekanntmachung eines Token-Leak-Vorfalls. Es gibt eine öffentliche Bestätigung der Maintainer (GitHub #700), dass die Legacy-URL-Query-Behandlung Datenschutzbedenken hervorgerufen hat, die schwerwiegend genug waren, eine Neuentwicklung anzustoßen. Das Fehlen eines bekannten Vorfalls ist nicht dasselbe wie das Fehlen eines Risikos.

Kann ich jwt.io selbst hosten?

Ja, der Quellcode ist verfügbar, aber Self-Hosting löst das Netzwerk-Vertrauensproblem nur dann, wenn Sie den Build tatsächlich auditieren und ihn aus von Ihnen kontrollierter Infrastruktur ausliefern. Für die meisten Teams ist ein bereits verifiziertes clientseitiges Tool weniger Aufwand und weniger Risiko als der Betrieb eines Forks.

Erfordert das Dekodieren eines JWT das Geheimnis?

Nein. Das Dekodieren von Header und Payload erfordert nur Base64URL-Dekodierung und JSON-Parsing — beides rein lokale Operationen. Das Geheimnis wird nur benötigt, um die Signatur zu verifizieren, was ein separater Schritt ist. Ein Tool, das Ihr Geheimnis verlangt, nur um die dekodierten Claims anzuzeigen, macht etwas falsch.

Warum wird mein Token als abgelaufen angezeigt, obwohl ich ihn gerade erst ausgestellt habe?

Der exp-Claim wird mit der lokalen Uhr verglichen. Decoder im Browser nutzen Ihre Systemuhr; CLI-Tools nutzen die Host-Uhr. Eine fehlerhafte Uhr — bei VMs und CI-Runnern verbreitet — lässt gültige Tokens abgelaufen erscheinen und umgekehrt. Synchronisieren Sie die Uhr (sudo sntp -sS time.apple.com oder sudo ntpdate pool.ntp.org) und prüfen Sie erneut.

Ist es tatsächlich sicher, einen Token in ein Tool einzufügen, das Sie als clientseitig verifiziert haben?

Ja, mit einer Einschränkung. Ein Tool, das heute clientseitig ist, muss es morgen nicht sein. Die Network-Tab-Prüfung sollte wiederholt werden, wenn Sie einem Tool einen besonders sensiblen Token anvertrauen, vor allem nach längerer Pause. Das Bookmarken des Tools oder eine Browser-Erweiterung, die vor ausgehenden Anfragen einer bestimmten Origin warnt, macht das günstiger.

Wie hängt das mit der breiteren Datenschutzhaltung von remove.sh zusammen?

Dieselbe Architektur gilt für jedes Entwickler-Tool auf der Seite. Die ausführlichere Argumentation findet sich in Client-Side Developer Tools: The Privacy-First Approach, wo JSON-Formatter, Hash-Generatoren, Base64-Decoder und die Web Crypto API im Detail behandelt werden.

Das Fazit

jwt.io ist eine populäre Bequemlichkeit, die eine Datenklasse — Anmeldeinformationen — verarbeitet, für die „populäre Bequemlichkeit” kein ausreichendes Vertrauensmodell ist. Die eigenen Maintainer haben öffentlich geschrieben, dass die Legacy-Seite Datenschutzprobleme hat, die schwerwiegend genug für eine Neugestaltung sind. Der Ersatz ist nicht das Redesign von jwt.io oder ein einzelner Konkurrent; es ist eine Gewohnheit.

Die Gewohnheit lautet: Bevor irgendein Tool einen Token zu sehen bekommt, führen Sie den Flugmodus-Test durch. Funktioniert es offline, ist es lokal. Funktioniert es nicht, finden Sie eines, das es tut — oder weichen Sie auf einen CLI-Einzeiler aus.

Der JWT Decoder auf remove.sh ist so gebaut, dass er diesen Test besteht. Öffnen Sie ihn, deaktivieren Sie das Netzwerk und dekodieren Sie einen Token. Wenn er weiterhin funktioniert — und das wird er — haben Sie soeben mit eigenen Augen verifiziert, dass kein Dritter diesen JWT jemals zu Gesicht bekommen wird.

Das ist die Antwort auf „jwt.io Alternative Datenschutz”. Keine andere Marke. Eine überprüfbare Eigenschaft.