Coder — Tipps & Tricks

Zurück zur Übersicht: Coder · Tool live öffnen: www.jpkc.com/tools/coder/

Das Manual erklärt jeden Reiter, die Beispiele 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:

Dekodieren beweist nichts. Header und Payload sind in einem JWT lediglich Base64URL-kodiert, nicht verschlüsselt. Jeder kann sie lesen — und jeder kann sie schreiben. Was der JWT-Reiter beim Einfügen anzeigt, ist das, was das Token behauptet. Dass dort "admin": true oder ein gültiges exp steht, heißt nur, dass das jemand hineingeschrieben hat.
Erst „Signature verified" zählt. Der Coder kann die Signatur prüfen — mit dem Secret bei HS256/384/512, mit dem öffentlichen Schlüssel (PEM, JWK oder JWKS) bei RS-, PS-, ES- und EdDSA-Tokens. Nur wenn dort „✓ Signature verified" steht, wurde das Token mit genau diesem Schlüssel signiert.
Die Status-Badges sind nur Anzeige. „Within its validity period", „Expired" und „Not valid yet" beruhen auf exp und nbf der Payload und der Uhr deines Rechners. Ohne geprüfte Signatur kann ein gefälschtes Token jeden beliebigen Zeitraum tragen.
Signatur ist nicht Berechtigung. Auch eine gültige Signatur sagt nichts darüber, ob das Token für deine Anwendung bestimmt ist. Aussteller (iss) und Empfänger (aud) prüft das Tool nicht — das muss dein Server tun, ebenso wie die echte Zugriffsentscheidung.
Ein Public Key gehört nie zu HS256. Behauptet ein Token alg: HS256, und du hast nur einen öffentlichen RSA- oder EC-Schlüssel, verweigert der Coder die Prüfung mit dem Hinweis auf eine Algorithmus-Verwechslung. Nimm das ernst: Genau so sehen gefälschte Tokens aus, die eine schlecht konfigurierte Bibliothek akzeptieren würde.
alg: none niemals akzeptieren. Ein Token ohne Signatur markiert das Tool rot mit „never accept it" — zu Recht.
Datenschutz spielt hier für dich: Dekodieren und Prüfen laufen komplett im Browser, Token, Secret und Schlüssel verlassen deinen Rechner nicht und werden nie gespeichert. Das ist ein echter Vorteil gegenüber vielen Online-JWT-Debuggern. Trotzdem gilt: Produktive Tokens und Secrets gehören nicht in fremde Hände — sieh sie dir an, aber teile sie nicht weiter.

Den richtigen Reiter wählen

Viele „funktioniert nicht"-Momente sind in Wahrheit der falsche Reiter oder Modus:

HTML: Anführungszeichen ja oder nein. Die Option Encode quotes ist standardmäßig an und macht den Text attributsicher. Brauchst du ihn nur zwischen Tags und stören dich die ", schalte sie aus.
URL: Component, Form oder Full URL. Für einen einzelnen Query-Wert oder ein Pfad-Segment nimm Component (%20 für Leerzeichen). Für Formular-Bodys und Systeme, die + erwarten, Form. Eine komplette Adresse kodierst du mit Full URL — mit Component würden auch : und / zu %3A und %2F.
Base64 und Base64URL. Beim Dekodieren musst du nicht unterscheiden — der Base64-Reiter akzeptiert beide Alphabete und fehlendes Padding. Beim Kodieren entscheidet die Option URL-safe. Ein JWT gehört trotzdem in den JWT-Reiter, weil der alle drei Teile auf einmal zerlegt und erklärt.
Unicode, HTML oder JSON? Numerische Entities für ein HTML-Dokument liefert der HTML-Reiter mit Non-ASCII as ä (dezimal, ä) oder der Unicode-Reiter mit Format HTML (hexadezimal, ä). Für einen kompletten JSON-String nimm den JSON-Reiter, für einzelne Zeichen in JavaScript-, Java- oder CSS-Quelltext den Unicode-Reiter.
JSON-Reiter ≠ JSON-Formatter. Der JSON-Reiter escapt und unescapt String-Werte, er formatiert oder validiert keine Dokumente. Dafür ist der JSON Editor das richtige Werkzeug.

Stolperfallen aus der Praxis

Doppelt kodiert? Schritt für Schritt zurück. Der HTML-Decoder nimmt genau eine Stufe zurück (&lt; → <). Das ist Absicht, damit du siehst, was passiert. Für die nächste Stufe klickst du Use output as input und noch einmal Decode; Strg+Z im Eingabefeld holt den vorherigen Stand zurück. Das funktioniert genauso bei mehrfach URL-kodierten Werten oder Base64 in Base64.
Binärdaten sind kein Fehler. Liefert Base64, Hex oder Quoted-Printable beim Dekodieren keinen Text, siehst du einen Hex-Dump. Die ersten Bytes verraten oft schon den Typ (89 50 4e 47 = PNG, 25 50 44 46 = PDF); der Download-Button liefert die vollständige Datei.
„… not valid UTF-8" beim URL-Decode bedeutet meist Altdaten in Latin-1 (%E4 statt %C3%A4 für ä). Solche Strings stammen aus alten Systemen und lassen sich im Coder nicht direkt lesen.
CSS-Escapes werden nur mit Format CSS dekodiert. Steht im Unicode-Reiter ein anderes Format, bleiben Sequenzen wie \E4 stehen — damit \n oder \f in normalem Text nicht versehentlich umgedeutet werden. Format auf CSS stellen, dann klappt es.
Punycode und ß. Der Coder setzt den Punycode-Algorithmus direkt um. Browser wenden vorher zusätzlich eigene Zuordnungsregeln an; bei Sonderfällen wie ß kann deren Ergebnis deshalb abweichen. Für die gängigen Umlaut-Domains ist das Ergebnis identisch.
Live-Modus bei großen Daten. Ab 512 KB pausiert er von selbst. Für große Base64-Blöcke klickst du ohnehin besser gezielt auf Encode oder Decode.
Data-URIs werden schnell riesig. Base64 vergrößert die Daten um rund ein Drittel; ab etwa 32 KB warnt das Tool, ab 10 MB fragt es nach. Für Icons und Mini-Assets prima, bei großen Bildern bremst die URI die Seite eher, als dass sie hilft. Und der MIME-Typ kommt aus der Browser-Erkennung — fehlt er, steht „unknown type" in der Infozeile.

Datenschutz: Merken nur bei Bedarf

Standardmäßig vergisst der Coder alles. Ohne deinen Klick auf Remember input and recent entries in this browser speichert er keine Eingaben — nur den gewählten Reiter und die Optionen.
Einschalten lohnt sich für harmlose Daten, etwa wenn du regelmäßig dieselben Punycode-Domains oder HTML-Schnipsel brauchst. Die letzten zehn Eingaben stehen dann im Menü Recent inputs bereit.
Auf geteilten Rechnern ausschalten und aufräumen. Base64-Strings und URLs enthalten oft Zugangsdaten. Forget stored entries löscht gespeicherte Eingaben und die Liste vollständig, auch Einträge älterer Tool-Versionen. JWTs speichert der Coder ohnehin nie.
Reiter direkt verlinken: Der Anker in der Adresszeile (#jwt, #punycode, #base64 …) öffnet den gewünschten Reiter. Ein Lesezeichen auf https://www.jpkc.com/tools/coder/#jwt bringt dich direkt zum Token-Prüfer.

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 — wenn du nicht nur kodieren, sondern zwischen Formaten konvertieren willst: Text zwischen 13 Kodierungen, Daten zwischen JSON, YAML, TOML, XML und INI.
JSON Editor — die perfekte Anschlussstation für eine dekodierte JWT-Payload oder einen unescapten JSON-String: formatieren, validieren, umbauen.
Hash-Tool — Hashes, HMAC und Prüfsummen, dazu Passwort-Hashes mit bcrypt, Argon2id und PBKDF2.
Generator — Passwörter, Schlüssel und TOTP-Codes, etwa ein ausreichend langes Secret für HS256-signierte Tokens.
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 Signatur prüfen.

Noch mehr Kontext: die Übersicht zum großen Bild, das Manual für jeden Reiter im Detail und die Beispiele für die Schritt-für-Schritt-Abläufe. Ausprobieren kannst du alles direkt im Tool.