Entwickler-Werkzeuge

Was Leute in einen Base64-Decoder einfügen, ist der Häufigkeit nach: ein JWT, ein Basic-Auth-Header, ein Webhook-Payload, eine Konfigurationsdatei. Drei von vier sind Zugangsdaten oder enthalten welche. Eine Seite, die das auf einem Server dekodiert, hat sie damit gesehen — und hat sie in ihren Request-Logs, ob das jemand wollte oder nicht.

Das ist kein theoretischer Einwand. Es ist der Grund, warum diese ganze Gattung von Website in vielen Unternehmen am Proxy blockiert ist, und warum dort, wo sie es nicht ist, meist eine Richtlinie existiert, die niemand liest. Alles auf dieser Seite ist Rechnerei, die ein Browser selbst erledigen kann; sie woanders laufen zu lassen ist eine Entscheidung, und zwar die falsche.

Die Seite ist statisches HTML von einem CDN. Beim ersten Tastendruck wird ein kleines JavaScript-Modul nachgeladen, einmal und danach aus dem Cache, und die Arbeit passiert in deinem Tab. Kein Request trägt, was du eingegeben hast, und das kannst du im Netzwerk-Panel nachsehen, statt es uns zu glauben.

Zwei ehrliche Einschränkungen. Die Seite selbst ist ein Request, also ist der Umstand, dass du hier warst, für uns und für dein Netz sichtbar. Und die Website trägt Werbung sowie, wenn du zustimmst, Analytics — beides sieht keinen Inhalt eines Textfelds, beides sind aber Anfragen an Dritte. Der Unterschied ist der zwischen dem, was du tippst, und der Tatsache, dass du hier bist: das erste bewegt sich nie, das zweite zwangsläufig.

Wenn Daten das Gerät nicht verlassen, findet keine Übermittlung an uns statt — und damit auch keine Auftragsverarbeitung für den Inhalt, den du einfügst. Das ist der praktisch entscheidende Punkt, wenn im Textfeld ein Kundendatensatz, eine Support-Nachricht oder ein Payload mit personenbezogenen Daten steht, und es ist der Grund, warum diese Werkzeuge auch dort benutzbar sind, wo eine Server-Variante es nicht wäre.

Was dennoch stattfindet, steht in der Datenschutzerklärung und wird hier nicht schöngeredet: der Seitenaufruf, die Werbe- und Analytics-Anfragen, die Einwilligung. Ein Werkzeug, das lokal rechnet, macht die Website nicht datenschutzneutral — es nimmt nur den einen Teil heraus, der am meisten wiegt.

Eine einzige Seite, die Base64, URLs und HTML in beide Richtungen hinter einem Auswahlfeld erledigt, wäre weniger Seiten und schlechter. Kodieren und Dekodieren scheitern unterschiedlich, werden unterschiedlich erklärt und unterschiedlich gesucht — wer eine kaputte Prozentsequenz vor sich hat und wer eine Query zusammenbaut, haben einander fast nichts zu sagen.

Also bekommt jede Richtung ihre eigene Seite, mit den Fehlern, die zu ihr gehören: was zu tun ist, wenn Base64 zu Bytes zerfällt, die kein Text sind, warum `encodeURIComponent` ein Ausrufezeichen stehen lässt und was das mit einer OAuth-Signatur macht. Das ergibt eine Seite, die zu lesen sich lohnt, und möglich ist es nur, weil sie nicht sechs Zielgruppen gleichzeitig bedient.

Sobald eine Werkzeugseite geladen ist, passiert alles lokal — sie arbeitet also im Zug, im Flugzeug und hinter einem Firmenproxy, der die Domain eine Stunde später sperrt. Es ist kein Service Worker installiert und nichts eingerichtet; eine Seite, die nie nach draußen ruft, hat schlicht nichts zu verlieren, wenn die Verbindung es tut.

Praktisch heißt das: Diese Werkzeuge sind genau in den Situationen benutzbar, in denen ein Online-Werkzeug sonst die falsche Wahl ist — auf einem fremden Rechner, in einem Netz, dem man nicht traut, mit Daten, die man eigentlich nicht bewegen sollte. Für diesen Fall sind sie gebaut.

Es gibt nichts anzumelden, weil es nichts zu verwalten gibt. Die Werkzeuge speichern zwischen zwei Besuchen nichts — das Schließen des Tabs löscht deine Eingabe, weil die Eingabe nirgendwo sonst existiert hat als in diesem Tab.

Es gibt auch keine Mengenbegrenzung, und zwar nicht aus Großzügigkeit: Wir zahlen für deine Rechenzeit nichts, also gibt es nichts zu deckeln. Die einzige Obergrenze ist, wie viel Text dein eigener Browser in einem Feld halten mag.

Auf diesen Seiten steht Payload, Token, Hash, Query-String und Base64 — nicht Nutzlast, Wertmarke, Streuwert oder Abfragezeichenkette. Das ist keine Bequemlichkeit, sondern die Sprache, in der in deutschen Teams tatsächlich über diese Dinge geredet und in der gesucht wird.

Wo ein deutsches Wort das übliche ist, steht es auch: Prüfsumme, Zeitstempel, Sonderzeichen, Umlaut. Die Regel ist nicht „so viel Deutsch wie möglich“, sondern „das Wort, das im Gespräch fällt“ — alles andere ergibt eine Seite, die korrekt übersetzt ist und die niemand findet.

Es gibt keinen HTML-, CSS- oder JavaScript-Formatierer, und das ist eine Entscheidung, keine Lücke. Ein korrekter braucht einen echten Parser; die dafür üblichen Bibliotheken sind mehrere Megabyte groß und wären eine eigene Lizenz- und Ladezeit-Entscheidung, und ein selbstgebauter zerstört Eingaben stillschweigend. Der JSON-Formatierer ist nur deshalb unbedenklich, weil der Parser dafür im Browser eingebaut ist.

Ebenso fehlt eine Markdown- oder HTML-Vorschau. Beides hieße, fremdes HTML in dieser Seite zu rendern — und genau das lehnt die Seite zum Dekodieren von HTML-Sonderzeichen mit ausführlicher Begründung ab, weil ein solcher Parser Netzwerkanfragen auslösen kann. Ein Argument, das auf einer Seite gilt, kann auf der nächsten nicht ignoriert werden.