Coder — Manual

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

Dieses Manual beschreibt jeden der zehn Reiter des Coder im Detail: was er tut, welche Optionen er hat, was rein- und rauskommt, welche Sonderfälle es gibt und wo die Grenzen liegen. Die Oberfläche ist auf Englisch — Reiter-, Button- und Optionsnamen werden hier deshalb in ihrer englischen Original-Schreibweise genannt (mit deutscher Erläuterung), damit du dich im echten Interface zurechtfindest.

Oberfläche und Bedienung

Das Tool ist eine einzige Karte mit einer Reiter-Leiste oben: HTML, URL, Base64, JSON, Unicode, Hex, Punycode, Quoted-Printable, JWT und Data URI. Auf schmalen Bildschirmen bricht die Leiste in mehrere Zeilen um.

Reiter wechseln: per Klick oder mit der Tastatur — steht der Fokus auf einem Reiter, wechseln Pfeil links/rechts zum Nachbarn, Pos1/Ende zum ersten bzw. letzten. Der zuletzt benutzte Reiter wird im Browser gemerkt und steht zusätzlich als Anker in der Adresszeile. Damit kannst du einen Reiter direkt verlinken, etwa https://www.jpkc.com/tools/coder/#jwt oder #punycode.

Die acht Text-Reiter (HTML bis Quoted-Printable) teilen sich eine gemeinsame Arbeitsfläche:

• Ein Infosatz über dem Editor erklärt kurz, was der aktuelle Reiter tut. Darunter stehen die Optionen des Reiters als Schalter oder Auswahllisten (Details in den Abschnitten unten). Eine geänderte Option rechnet ein vorhandenes Ergebnis sofort neu, und zwar aus dem Text im Feld Input; alle Optionen bleiben im Browser gespeichert.
• Zwei Editorfelder nebeneinander (auf schmalen Bildschirmen untereinander): Input links, Output rechts. Beide sind ACE-Editoren mit Zeilenumbruch; die Ausgabe ist schreibgeschützt. Encode und Decode schreiben das Ergebnis in die Ausgabe — deine Eingabe bleibt unverändert stehen.
• Im Kopf des Input-Felds: Recent inputs (Uhr-Symbol, nur sichtbar, wenn du das Merken eingeschaltet hast, siehe Speichern und Datenschutz) und Clear input (X) — leert Ein- und Ausgabe; Strg+Z im Eingabefeld holt den Text zurück.
• Im Kopf des Output-Felds: Use output as input (Doppelpfeil) übernimmt das Ergebnis als neue Eingabe — praktisch für mehrstufige Kodierungen; Strg+Z im Eingabefeld macht das in einem Schritt rückgängig. Copy output legt das Ergebnis in die Zwischenablage, Download output speichert es als Textdatei (<codec>-encoded.txt bzw. <codec>-decoded.txt mit dem internen Kürzel des Reiters und der zuletzt gewählten Richtung Encode oder Decode, z. B. base64-encoded.txt, beim Reiter Quoted-Printable qp-encoded.txt) oder bei binären Ergebnissen als Datei.
• Unter den Feldern: Encode (Tastenkürzel Strg+Enter, auf dem Mac Cmd+Enter) und Decode (Strg+Umschalt+Enter bzw. Cmd+Umschalt+Enter). Die Kürzel wirken, solange der Cursor im Eingabefeld steht.
• Schalter Live (convert while typing) — rechnet schon beim Tippen (mit 200 ms Verzögerung) in der zuletzt benutzten Richtung. Standardmäßig aus; ab 512 KB Eingabe pausiert der Live-Modus mit einem Hinweis, dann klickst du Encode/Decode von Hand.
• Eine Statuszeile unter den Buttons meldet Ergebnis und Größe („Encoded · 17 → 28 characters", beim Dekodieren von Base64, Hex und Quoted-Printable „Decoded · … of UTF-8 text") oder „(nothing to change)", wenn sich nichts geändert hat. Fehler erscheinen dort in Rot, meist mit Position und Ursache.

JWT und Data URI haben eigene Ansichten ohne Encode-/Decode-Buttons: Sie werten aus, sobald du etwas einfügst.

Architektur: alles clientseitig

Wichtig für Verständnis und Datenschutz: Der Server liefert nur die HTML-Seite und den ACE-Editor aus. Das Encoden und Decoden passiert vollständig in deinem Browser per JavaScript — Punycode etwa über eine eigene Implementierung nach RFC 3492, die JWT-Signaturprüfung über die Web-Crypto-Schnittstelle des Browsers. Es gibt keine serverseitige Verarbeitung, keinen API-Call und keinen Upload deiner Eingaben — auch nicht beim JWT-Reiter, beim Prüfen mit Secret oder Schlüssel oder bei der Data-URI-Erzeugung. Deine Tokens, Schlüssel, Dateien und Strings bleiben lokal.

Speichern und Datenschutz

Was der Coder im Browser (localStorage) ablegt, ist klar getrennt:

• Immer gespeichert werden nur Einstellungen: der zuletzt benutzte Reiter und die Optionen der Text-Reiter einschließlich des Live-Schalters.
• Nur auf Wunsch speichert der Coder Inhalte. Der Schalter Remember input and recent entries in this browser in der Fußzeile der Karte ist standardmäßig aus — das Tool begründet das selbst: Base64-Strings und URLs enthalten oft Zugangsdaten. Schaltest du ihn ein, merkt sich der Coder die aktuelle Eingabe sofort beim Einschalten und danach bei jedem Klick auf Encode oder Decode (bis 100.000 Zeichen, sie steht beim nächsten Besuch wieder im Feld) und führt eine Liste der letzten 10 Eingaben, die du über Recent inputs wieder aufrufst. Live-Durchläufe landen nicht in der Liste. Schaltest du das Merken wieder aus, wird die gespeicherte Eingabe gelöscht und die Liste ausgeblendet; endgültig entfernt sie erst Forget stored entries.
• Forget stored entries löscht die gespeicherte Eingabe und die Liste der letzten Eingaben, und zwar einschließlich der Listen, die ältere Versionen des Tools für URL, Base64 und JSON angelegt hatten.
• JWTs werden nie gespeichert, auch nicht mit eingeschaltetem Merken; dasselbe gilt für Secrets und Schlüssel im JWT-Reiter.

HTML — Entities

Der Reiter HTML wandelt Zeichen in HTML-Entities um und zurück.

• Encode: & → &, < → <, > → > — immer, und zwar so, dass das & der erzeugten Entities nicht erneut kodiert wird.
• Option Encode quotes (" ') — standardmäßig an: zusätzlich " → " und ' → '. Das brauchst du, wenn der Text in einem Attributwert landet (title="…", alt="…"). Steht er nur zwischen Tags, kannst du die Option ausschalten.
• Option Non-ASCII as ä — schreibt zusätzlich jedes Zeichen jenseits von ASCII als dezimale Entity, aus ä wird ä, aus einem Emoji 😀. Nützlich für Umgebungen, die kein UTF-8 vertragen.
• Decode: versteht alle benannten Entities (©,  , € …) sowie numerische in dezimaler (€) und hexadezimaler Form (€) — jeweils mit abschließendem Semikolon. Schreibweisen ohne Semikolon wie &copy oder &#228 bleiben unverändert stehen. Dekodiert wird in einem Durchlauf: Aus < wird <, nicht < — doppelt kodierter Text wird also genau eine Stufe zurückgenommen. Ungültige Codepoints werden zum Ersatzzeichen �, unbekannte Namen bleiben in der Regel unverändert stehen. Ausnahme: Beginnt ein unbekannter Name mit einem Entity-Namen, den Browser auch ohne Semikolon kennen, löst der Browser diesen Anfang auf — aus &notit; wird ¬it;. Die Ausgabe zeigt das Ergebnis mit HTML-Syntax-Highlighting.

Die Namen der benannten Entities löst der Browser selbst auf; dabei wird nie Markup aus deiner Eingabe erzeugt oder ausgeführt.

URL — URL-Encoding

Der Reiter URL prozent-kodiert einen String und dekodiert ihn wieder. Die Auswahlliste Mode bestimmt, wie:

• Component (encodeURIComponent) — Standard. Für einzelne Query-Werte und Pfad-Segmente: Alles außer Buchstaben, Ziffern und - _ . ~ wird kodiert, zusätzlich ! ' ( ) * nach RFC 3986. Leerzeichen werden zu %20.
• Form (space = +) — wie Component, aber Leerzeichen als +, also im Stil von application/x-www-form-urlencoded (HTML-Formulare). Beim Decode wird + wieder zum Leerzeichen.
• Full URL (encodeURI) — kodiert eine komplette URL und lässt dabei die Strukturzeichen : / ? # & = stehen; Umlaute und Leerzeichen werden kodiert. Beim Decode bleiben in diesem Modus die Escapes reservierter Zeichen stehen (%2F, %3F, %23, %26, %3D, %3A, %40, %2B, %24, %2C, %3B) — aus q=a%26b wird also nicht q=a&b. Zum vollständigen Dekodieren wählst du Component.

Beim Decode meldet das Tool kaputte Sequenzen mit Position („Malformed percent-encoding at position 4") und erkennt, wenn die Bytes kein gültiges UTF-8 sind — typisch für Latin-1-kodierte Altdaten wie %E4 für ä.

Query-Parameter als Tabelle: Enthält die Eingabe (beim Encode) bzw. das Ergebnis (beim Decode) einen Query-String nach ? oder sieht der Text selbst wie name=wert&name2=wert2 aus, erscheint unter der Ausgabe eine Tabelle Query parameters mit Name und dekodiertem Wert jedes Parameters.

Base64 — Text und Dateien

Der Reiter Base64 kodiert Text nach Base64 und dekodiert Base64 zurück.

• Encode: wandelt den Text UTF-8-sicher um, sodass Umlaute, Akzente und Emojis korrekt durchlaufen.
• Option URL-safe (-_, no padding) — erzeugt die Base64URL-Variante (- und _ statt + und /, ohne =-Padding), wie sie in JWTs und URLs vorkommt.
• Option Wrap at 76 characters (MIME) — bricht die Ausgabe nach 76 Zeichen um, wie in E-Mails üblich.
• Encode a file… — kodiert eine beliebige Datei von deinem Rechner nach Base64, mit den Optionen, die beim Einlesen eingestellt sind. Änderst du danach eine Option, rechnet das Tool den Text im Feld Input neu und verwirft das Datei-Ergebnis (bei leerem Input bleibt die Ausgabe leer) — für andere Optionen wählst du die Datei erneut. Ab 25 MB fragt das Tool nach, weil das viel Zeit und Speicher kostet. Für eine fertige data:-URI nimm den Reiter Data URI.
• Decode: ist großzügig — es akzeptiert Standard- und URL-safe-Alphabet, fehlendes Padding, Leerzeichen und Zeilenumbrüche und sogar eine komplette Data-URI (der Teil bis ;base64, wird abgeschnitten). Ungültige Eingaben werden präzise gemeldet: ein unzulässiges Zeichen mit Position, = mitten in den Daten oder eine Länge, die auf abgeschnittene Daten hindeutet.

Binäre Ergebnisse: Ist das Dekodierte kein lesbarer UTF-8-Text (etwa ein Bild oder ein ZIP), zeigt die Ausgabe einen klassischen Hex-Dump (Offset, Bytes, ASCII-Spalte; angezeigt werden die ersten 64 KB). Darunter stehen Größe und erkannter Dateityp sowie ein Button Download decoded. für die vollständigen Daten. Den Typ erkennt das Tool an den ersten Bytes (PNG, JPEG, GIF, WebP, ICO, PDF, ZIP, GZIP, WOFF2); PNG, JPEG, GIF, WebP und ICO bekommen zusätzlich eine Bildvorschau. Ein binäres Ergebnis lässt sich nicht per Use output as input weiterverwenden — dafür gibt es den Download. Dasselbe Verhalten gilt für Hex und Quoted-Printable.

JSON — String escapen und unescapen

Der Reiter JSON behandelt JSON-String-Werte, nicht ganze JSON-Dokumente.

• Encode: escapt Text so, dass er gültig zwischen die Anführungszeichen eines JSON-Strings passt: " → \", \ → \\, Zeilenumbruch → \n, Wagenrücklauf → \r, Tabulator → \t, dazu \b, \f und alle übrigen Steuerzeichen als \u00XX.
• Option Add surrounding quotes — setzt das Ergebnis gleich in Anführungszeichen.
• Option Escape non-ASCII — schreibt zusätzlich alle Zeichen ab U+007F als \uXXXX (aus ä wird \u00e4, Emojis werden zu einem Surrogatpaar). Damit bleibt die Ausgabe reines ASCII.
• Decode: löst alle JSON-Escapes auf, einschließlich \uXXXX, \b, \f und \/. Umschließende Anführungszeichen erkennt und entfernt das Tool selbst; rohe Zeilenumbrüche und Tabs in der Eingabe (etwa aus einem mehrzeilig eingefügten Text) werden toleriert. Ist die Eingabe kein gültiger JSON-String, meldet das Tool die ungefähre Position und weist auf ein unescaptes " hin, wenn das die Ursache ist.

Für das Formatieren, Validieren oder Umstrukturieren ganzer JSON-Dokumente nutze den JSON Editor.

Unicode — Escape-Sequenzen

Der Reiter Unicode schreibt Zeichen als Escape-Sequenzen verschiedener Sprachen. Die Auswahlliste Format bietet die folgenden Formate; in der Liste steht vor jedem Namen ein Beispiel, der Name selbst in Klammern, etwa U+00E4 (code points):

Format	Beispiel für ä	Einsatz
JavaScript, JSON, Java (Standard)	\u00E4	Zeichen außerhalb der Basisebene (z. B. Emojis) als Surrogatpaar \uD83D\uDE00
ES2015	\u{E4}	moderne JavaScript-Syntax, Emojis als \u{1F600}
CSS	\E4	in CSS-Strings und content; das folgende Leerzeichen beendet das Escape
HTML	ä	hexadezimale numerische Entity
code points	U+00E4	Code Points zum Nachschlagen, leerzeichengetrennt

• Standardmäßig werden nur Nicht-ASCII-Zeichen escapt; mit der Option Escape ASCII too auch alle anderen. Das Format code points listet ohnehin jedes Zeichen.
• Decode: erkennt die Formate automatisch und gleichzeitig — \uXXXX (Surrogatpaare werden wieder zu einem Zeichen), \u{…}, \UXXXXXXXX (Hex-Ziffern groß oder klein: \U0001F600 und \U0001f600 werden beide zu 😀), \xXX, &#x…;, &#…; und U+…. CSS-Escapes (\E4) dekodiert das Tool nur, wenn als Format CSS gewählt ist, weil sie sich sonst mit Sequenzen wie \n oder \f überschneiden würden.

Hex — Bytes als Hexadezimal

Der Reiter Hex zeigt Text als UTF-8-Bytes in Hexadezimal — Grüße wird zu 47 72 c3 bc c3 9f 65.

• Auswahlliste Separator: none (4772c3bc…), space (Standard) oder colon (47:72:c3:…).
• Option Uppercase — Großbuchstaben (C3 BC statt c3 bc).
• Encode a file… — wie im Base64-Reiter, nur mit Hex-Ausgabe.
• Decode: ignoriert Leerzeichen, Zeilenumbrüche, Doppelpunkte, Kommas, Bindestriche sowie die Präfixe 0x und \x. Damit kannst du Hex aus Debuggern, Paketmitschnitten oder C-Quelltext direkt einfügen. Bei ungültigen Zeichen oder einer ungeraden Zahl von Ziffern meldet das Tool den Fehler. Ergeben die Bytes keinen Text, greift die Binär-Ansicht mit Hex-Dump und Download (siehe Base64).

Punycode — internationale Domains

Der Reiter Punycode übersetzt internationale Domainnamen (IDN) zwischen Unicode- und ASCII-Form, wie sie im DNS steht: bücher.de ↔ xn--bcher-kva.de.

• Die Eingabe wird zeilenweise verarbeitet; jede Zeile darf eine Domain, eine ganze URL oder eine E-Mail-Adresse sein. Umgewandelt wird jeweils nur der Host — Schema, Pfad, Query, Port und der Teil vor dem @ bleiben unverändert.
• Encode: Jedes Label (der Teil zwischen zwei Punkten) mit Nicht-ASCII-Zeichen wird normalisiert (Unicode-NFC), kleingeschrieben und als xn--… kodiert; reine ASCII-Labels bleiben, wie sie sind.
• Decode: wandelt alle Labels mit xn---Präfix zurück. Ungültiges Punycode wird mit dem betroffenen Label gemeldet.

Die Umsetzung folgt dem Punycode-Algorithmus aus RFC 3492. Die zusätzliche Zeichen-Zuordnung, die Browser vor der Kodierung anwenden (UTS 46), bildet das Tool nicht nach; bei Sonderfällen wie ß kann das Ergebnis deshalb von der Browser-Adresszeile abweichen.

Quoted-Printable — E-Mail-Kodierung

Der Reiter Quoted-Printable setzt die Kodierung aus E-Mail-Quelltexten nach RFC 2045 um, auf Basis von UTF-8.

• Encode: Druckbare ASCII-Zeichen bleiben stehen; = und alle anderen Bytes (Umlaute, Steuerzeichen) werden zu =XX — aus ü wird =C3=BC. Leerzeichen und Tabs am Zeilenende werden ebenfalls kodiert. Zeilen werden mit einem weichen Umbruch (= am Zeilenende) auf höchstens 76 Zeichen begrenzt; deine eigenen Zeilenumbrüche bleiben erhalten.
• Decode: entfernt die weichen Umbrüche und setzt =XX-Sequenzen wieder zu Bytes zusammen. Das Ergebnis erscheint als Text, oder — falls es kein UTF-8-Text ist — in der Binär-Ansicht.

JWT — dekodieren und Signatur prüfen

Der Reiter JWT zerlegt ein JSON Web Token, erklärt seinen Inhalt und prüft auf Wunsch die Signatur. Einen Decode-Button gibt es nicht: Das Tool wertet aus, sobald du das Token in das Feld Token einfügst oder tippst.

Eingabe: Ein vorangestelltes Bearer (etwa aus einem Authorization-Header kopiert) und Leerzeichen oder Zeilenumbrüche im Token werden ignoriert.

Format-Prüfung:

• Ein Token mit fünf Teilen erkennt das Tool als verschlüsseltes Token (JWE) und zeigt nur dessen Header — die Payload lässt sich nur mit dem privaten Schlüssel des Empfängers lesen.
• Hat das Token nicht genau drei Teile, meldet das Tool „Not a JWT: expected 3 parts separated by dots, found …".
• Header und Payload müssen gültiges Base64URL mit UTF-8 sein, der Header ein JSON-Objekt. Eine Payload, die kein JSON ist, wird als Text gezeigt (Hinweis „Payload is not JSON — shown as text").
• Bei einem Fehler verschwindet das vorherige Ergebnis — es bleibt nie ein altes Token stehen.

Anzeige:

• Header und Payload als eingerücktes JSON, jeweils mit eigenem Copy-Button.
• Claims — eine Tabelle mit jedem Payload-Feld, seinem Wert und seiner Bedeutung im Klartext für die gängigen Claims (iss, sub, aud, exp, nbf, iat, jti, auth_time, azp, nonce, scope/scp, roles, email, name, sid u. a.). Zeitangaben (exp, nbf, iat, auth_time, updated_at) stehen zusätzlich als lokales Datum, relative Zeit und ISO-Zeitstempel daneben.
• Signature mit dem Algorithmus aus dem Header und der Signatur als roher String.

Status-Badges über dem Ergebnis, berechnet aus den Feldern der Payload und der aktuellen Uhrzeit:

• „Expired …" (abgelaufen, mit Relativzeit), „Not valid yet — becomes valid …" (nbf liegt in der Zukunft), „Within its validity period — expires …" oder „No expiry (exp) set".
• „"exp" is not a number", wenn der Ablaufzeitpunkt kein Zahlenwert ist.
• „Unsigned token (alg: …) — never accept it", wenn der Header alg: none angibt oder die Signatur fehlt; in der Klammer steht der Algorithmus aus dem Header (bzw. missing, wenn alg fehlt).

Signatur prüfen: Im Signatur-Bereich gibst du den Schlüssel ein und klickst Verify signature. Feld und Optionen passen sich dem Algorithmus des Tokens an:

• HMAC (HS256, HS384, HS512): Feld Secret für das gemeinsame Geheimnis. Mit dem Schalter Secret is Base64-encoded wird das Secret vorher Base64- bzw. Base64URL-dekodiert — nötig, wenn dein Server das Secret als Base64-String verwaltet. Statt eines Secrets nimmt das Feld auch einen JWK mit "kty": "oct" oder ein JWKS mit solchen Schlüsseln an. Beginnt der Inhalt mit {, liest das Tool ihn immer als JWK; ein Secret, das selbst mit { anfängt, kodierst du deshalb vorher nach Base64 und schaltest Secret is Base64-encoded ein.
• RSA (RS256/384/512), RSA-PSS (PS256/384/512), ECDSA (ES256/384/512) und EdDSA (Ed25519): Feld Public key für einen öffentlichen Schlüssel als PEM (-----BEGIN PUBLIC KEY-----), als JWK oder als JWKS (Schlüsselsatz mit "keys": […]). Aus einem JWKS wählt das Tool den Schlüssel mit der kid aus dem Token-Header, bei nur einem Schlüssel diesen.
• Ergebnis: „✓ Signature verified — the token was signed with this key." oder „✗ Signature does NOT match this key/secret."

Schutzmechanismen und Grenzen der Prüfung:

• Algorithmus-Verwechslung wird abgewiesen: Behauptet ein Token HMAC (HS…), du gibst aber einen öffentlichen Schlüssel oder ein Zertifikat ein, verweigert das Tool die Prüfung mit dem Hinweis, das Token als gefälscht zu behandeln. Hintergrund ist ein bekannter Angriff, bei dem der öffentliche Schlüssel als HMAC-Secret missbraucht wird.
• Ein JWK muss zum Algorithmus passen (kty oct, RSA, EC bzw. OKP), und ein im JWK eingetragenes alg muss mit dem des Tokens übereinstimmen.
• Zertifikate (BEGIN CERTIFICATE) und RSA-Schlüssel im PKCS#1-Format (BEGIN RSA PUBLIC KEY) kann der Browser nicht importieren; das Tool nennt dir dann den passenden openssl-Befehl zur Umwandlung in BEGIN PUBLIC KEY. Einen PKCS#1-Schlüssel wandelt alternativ das PKI-Tool um: Es gibt ihn als BEGIN PUBLIC KEY aus (Show PEM, Copy PEM, Download als public-key.pem).
• Ed25519 setzt einen aktuellen Browser voraus. Andere Algorithmen meldet das Tool als nicht unterstützt; bei alg: none gibt es nichts zu prüfen.
• Geprüft wird nur die Signatur. Ob Aussteller (iss) und Empfänger (aud) stimmen, bewertet das Tool nicht; die Gültigkeits-Badges ersetzen keine serverseitige Prüfung. Tokens erzeugt der Coder nicht.

Data URI — Datei zu Data-URI und zurück

Der Reiter Data URI hat zwei Hälften.

File → Data URI wandelt eine beliebige Datei in eine Base64-kodierte data:-URI um:

1. Du ziehst eine Datei auf das Feld Drop a file here or choose one oder wählst sie über den Dateidialog aus.
2. Der Browser liest sie lokal ein; ein Fortschrittsbalken zeigt den Lese-Status. Bei Dateien über 10 MB fragt das Tool vorher nach und nennt die zu erwartende Größe der URI — so große Data-URIs sind unpraktisch und können die Seite einfrieren.
3. Eine Infozeile zeigt Dateiname, MIME-Typ (oder „unknown type", wenn der Browser keinen kennt), Dateigröße und Größe der Data-URI. Ab rund 32 KB rät das Tool dazu, lieber eine normale Datei auszuliefern.
4. Über Output as wählst du das Format der Ausgabe: Data URI (data:<mimetype>;base64,…), CSS background-image (background-image: url("…");), HTML <img> (mit dem Dateinamen als alt-Text), Markdown image (![name](…)) oder Base64 only (nur die kodierten Daten). Copy legt das Ergebnis in die Zwischenablage; das Ausgabefeld ist schreibgeschützt.
5. Bilder bekommen eine Vorschau.

Data URI → File geht den umgekehrten Weg: Du fügst eine data:-URI ein, das Tool dekodiert sie sofort.

• Akzeptiert werden Base64- und prozent-kodierte Data-URIs; fehlt der MIME-Typ, gilt text/plain.
• Angezeigt werden MIME-Typ, Größe und Kodierung sowie ein Button Download file. — die Endung kommt aus den ersten Bytes der Daten oder, falls die nichts verraten, aus dem MIME-Typ.
• Eine Vorschau gibt es für echte Rasterbilder (PNG, JPEG, GIF, WebP, ICO) und für Text (die ersten 5000 Zeichen). SVG wird bewusst nicht angezeigt, weil es Skripte enthalten kann — lade es stattdessen herunter. Aus demselben Grund speichert der Download die Daten immer als neutralen Dateityp.

Base64 vergrößert Daten um rund ein Drittel. Data-URIs lohnen sich deshalb vor allem für kleine Assets wie Icons; die Datei wird in beiden Richtungen nicht hochgeladen.

Grenzen — kompakt

• HTML Decode nimmt genau eine Kodierungsstufe zurück; unbekannte Entity-Namen und Entities ohne abschließendes Semikolon bleiben stehen.
• URL kodiert je nach Mode unterschiedlich — für Query-Werte Component oder Form, für ganze Adressen Full URL; Full URL lässt beim Decode Escapes reservierter Zeichen (%2F, %26 …) stehen. Nicht-UTF-8-Altdaten (Latin-1) lassen sich nicht dekodieren.
• JSON behandelt String-Werte, keine ganzen Dokumente.
• Unicode dekodiert CSS-Escapes nur bei gewähltem Format CSS. \u und \U unterscheiden Groß- und Kleinschreibung wie in C und Python: \u erwartet genau vier Hex-Ziffern, \U genau acht.
• Punycode setzt RFC 3492 um, aber keine UTS-46-Zuordnung; Sonderfälle wie ß können vom Browser abweichen.
• Binäre Ergebnisse zeigt die Ausgabe nur bis 64 KB als Hex-Dump; der Download enthält alles. Datei-Kodierung fragt ab 25 MB nach, Data-URIs ab 10 MB; eine kodierte Datei rechnet eine Optionsänderung nicht neu.
• Live-Modus pausiert ab 512 KB Eingabe.
• JWT prüft nur die Signatur, nicht iss/aud; keine Token-Erzeugung, keine Entschlüsselung von JWE, keine Zertifikate oder PKCS#1-Schlüssel.
• Data URI hängt beim Erzeugen am vom Browser gemeldeten MIME-Typ; SVG wird beim Rückweg nicht in der Vorschau gezeigt.

Für das große Bild und die Zielgruppen siehe die Übersichtsseite, für konkrete Abläufe die Beispiele. Ausprobieren kannst du alles direkt im Tool.