# Coder — Tipps & Tricks > Kniffe für den Coder: JWT-Signatur wird nicht geprüft (Sicherheitshinweis), den richtigen Reiter wählen, Stolperfallen und Kombi mit anderen Tools. Source: https://www.jpkc.com/db/tools/coder/tips/ Zurück zur Übersicht: [Coder](https://www.jpkc.com/db/tools/coder/) · Tool live öffnen: [www.jpkc.com/tools/coder/](https://www.jpkc.com/tools/coder/) Das [Manual](https://www.jpkc.com/db/tools/coder/manual/) erklärt jeden Reiter, die [Beispiele](https://www.jpkc.com/db/tools/coder/examples/) zeigen die Abläufe. Hier geht es um das, was beides voraussetzt, aber selten dabeisteht: wann ein Reiter etwas anderes tut, als du erwartest, und worauf du beim sicheren Umgang achten solltest. ## JWT: Decode ist nicht Verify Der wichtigste Punkt zuerst, weil hier ein gefährliches Missverständnis lauert: - **Der JWT-Reiter dekodiert nur — er verifiziert nicht.** Header und Payload sind in einem JWT lediglich **Base64URL-kodiert, nicht verschlüsselt**. Jeder kann sie lesen, und genau das macht das Tool sichtbar. Es prüft aber **nicht** die Signatur und sagt dir **nicht**, ob das Token echt, gültig signiert oder manipuliert ist. - **Vertraue einer dekodierten Payload niemals als Berechtigungsnachweis.** Dass dort `"admin": true` oder ein nicht abgelaufenes `exp` steht, heißt nur, dass das jemand *hineingeschrieben* hat — nicht, dass es ein Server akzeptiert. Die echte Verifikation (Signaturprüfung gegen das Secret bzw. den öffentlichen Schlüssel) passiert immer **serverseitig** und ist hier bewusst nicht enthalten. - **Die Ablauf-Badges sind nur Anzeige.** „Gültig, läuft … ab" und „Abgelaufen" beruhen rein auf den Feldern `exp`/`iat` der **unverifizierten** Payload. Ein gefälschtes Token kann jedes beliebige `exp` tragen. - **Datenschutz spielt hier für dich:** Weil der Coder rein clientseitig arbeitet, verlässt das Token deinen Browser **nicht**. Das ist ein echter Vorteil gegenüber vielen Online-JWT-Debuggern, die das Token an einen Server schicken. Trotzdem gilt die generelle Vorsicht: Produktive Tokens enthalten oft sensible Claims — sieh sie dir an, aber teile sie nicht weiter. ## Den richtigen Reiter wählen Viele „funktioniert nicht"-Momente sind in Wahrheit der falsche Reiter: - **HTML vs. HTML+.** Steht dein Text zwischen Tags, reicht **HTML** (`& < >`). Landet er in einem Attributwert, nimm **HTML+** — sonst zerbrechen die Anführungszeichen das Attribut. Beide dekodieren nur die **selbst erzeugten** Entities; ` `, `©` oder numerische Entities löst keiner der beiden auf. - **Base64 ist nicht Base64URL.** Der **Base64**-Reiter erwartet das Standard-Alphabet (`+ /`, `=`-Padding). Ein JWT-Segment ist **Base64URL** (`- _`, oft ohne Padding) und scheitert im Base64-Reiter. Für Tokens immer den **JWT**-Reiter nehmen — der dekodiert Base64URL korrekt. - **JSON-Reiter ≠ JSON-Formatter.** Der **JSON**-Reiter escapt/unescapt **String-Literale** (`\\ \" \n \r \t`), er formatiert oder validiert keine Dokumente. Fürs Formatieren, Validieren und Umstrukturieren ganzer JSON-Dateien ist der [JSON Editor](https://www.jpkc.com/db/tools/json/) das richtige Werkzeug. ## Stolperfallen aus der Praxis - **URL-Encoding nutzt `+` für Leerzeichen.** Der Coder kodiert im Formular-Stil (`application/x-www-form-urlencoded`), nicht mit `%20`. Für Query-Strings ist das korrekt; für einen Pfad-Bestandteil, in dem ein `+` wörtlich gemeint ist, musst du das im Kopf behalten. - **Encode und Decode überschreiben das Feld.** Das Ergebnis wird in dasselbe Eingabefeld zurückgeschrieben. Willst du Original und Resultat nebeneinander, kopier das Original vorher mit **Copy** heraus. - **JSON-Escape deckt nicht alles ab.** Unicode-Escapes (`\uXXXX`) sowie `\b` und `\f` werden nicht behandelt — nur `\\ \" \n \r \t`. Bei exotischeren Steuerzeichen also nicht überrascht sein. - **Ungültiger Input wird gemeldet, nicht stillschweigend verbogen.** Kein gültiges Base64, eine kaputte URL-Sequenz oder ein JWT ohne drei Teile führt zu einer klaren Fehlermeldung — keine halb-kaputte Ausgabe, die du erst später bemerkst. - **Data-URIs werden schnell riesig.** Base64 vergrößert die Daten um rund ein Drittel. Für Icons und Mini-Assets prima; bei großen Bildern oder gar Videos wird die URI unhandlich lang und bremst die Seite eher, als dass sie hilft. Und der MIME-Typ kommt aus der Browser-Erkennung — fehlt er, steht `n/a`. ## Mit anderen JPKCom-Tools kombinieren Der Coder ist das schnelle Schweizer Taschenmesser für Encode/Decode. Für alles Größere übernehmen Nachbar-Tools: - **[Convertor PRO](https://www.jpkc.com/db/tools/convertor/)** — wenn du nicht nur encoden/decoden, sondern zwischen Formaten **konvertieren** willst: HTML/XML, Unicode, UTF-8, Hexadezimal, YAML, JSON, TOML. - **[JSON Editor](https://www.jpkc.com/db/tools/json/)** — die perfekte Anschlussstation für eine dekodierte JWT-Payload oder einen unescapten JSON-String: formatieren, validieren, umbauen. - **[Generator](https://www.jpkc.com/db/tools/generator/)** und **[Hash Generator](https://www.jpkc.com/db/tools/hash/)** — die Security-Nachbarn neben dem JWT-Reiter: Passwörter, BCrypt-/Argon2-Hashes, TOTP-Codes bzw. MD5/SHA-Hashes. - **[Beautify](https://www.jpkc.com/db/tools/beautify/)** — wenn der HTML- oder JavaScript-Schnipsel, den du gerade escapt hast, auch noch sauber formatiert werden soll. Workflow-Muster: kodieren/dekodieren im Coder → bei Bedarf im passenden Nachbar-Tool weiterverarbeiten. Ein konkreter Durchlauf steht im [Beispiel 2: Ein JWT dekodieren und die Payload lesen](https://www.jpkc.com/db/tools/coder/examples/#beispiel-2-ein-jwt-dekodieren-und-die-payload-lesen). --- Noch mehr Kontext: die [Übersicht](https://www.jpkc.com/db/tools/coder/) zum großen Bild, das [Manual](https://www.jpkc.com/db/tools/coder/manual/) für jeden Reiter im Detail und die [Beispiele](https://www.jpkc.com/db/tools/coder/examples/) für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im [Tool](https://www.jpkc.com/tools/coder/).