12 kostenlose Browser-Tools, selbst gebaut, jetzt auf GitHub

Ich hab in den letzten zwei Monaten zwölf kostenlose Tools gebaut, alle live unter eric-hinzpeter.de/tools. Von der Kontrastprüfung über die Bildkonvertierung bis zum Markdown-Editor und UTM-Generator ist so ziemlich alles dabei, was mir im eigenen Arbeitsalltag gefehlt hat. Jedes davon läuft komplett im Browser: kein Upload, kein Account, keine Anfrage an einen Server irgendwo dazwischen. Und seit dieser Woche ist auch der Code dahinter öffentlich einsehbar.

Dieser Post ist die Übersicht: was die zwölf Tools jeweils können, wie sie gebaut sind, und wie das neue Repo technisch funktioniert. Vier von ihnen haben eigene Bau-Geschichten, die ausführlich genug sind für eigene Posts, die parallel dazu entstehen. Hier in diesem Post geht es um die Breite, nicht um die Tiefe eines einzelnen Tools.

Was die Werkzeugkiste hergibt

Die zwölf Tools verteilen sich grob auf drei Gruppen: Text- und Content-Checks, Format-Konvertierung und Kampagnen- oder SEO-Werkzeuge.

Bei den Text-Tools gibt es einen KI-Floskeln-Checker, der KI-typische Muster in eingefügtem Text markiert. Warum ich ihn einem klassischen KI-Detektor vorziehe, steht ausführlich in KI-Floskeln prüfen statt KI-Detektor. Dazu kommt ein Lesbarkeits-Checker, der englischen Text mit Flesch Reading Ease bewertet und deutschen Text mit der Amstad-Formel. Die eigene Geschichte dazu steht in Lesbarkeit auf Deutsch messen. Und ein Markdown-Editor mit Live-Vorschau, der die Formatierung beim Einfügen in Word oder Gmail zuverlässig erhält.

Zur Konvertierung gehört ein ChatGPT-Textkonverter, der eine eingefügte Konversation in sauberes Markdown, HTML oder ein Word-Dokument umwandelt. Dazu kommt ein Bildkonverter, der WebP, AVIF, JPG und PNG verarbeitet, dazu Kamera-RAW-Dateien und HEIC-Fotos direkt vom iPhone. Warum gerade das RAW-Format bei diesem Tool keinen Upload braucht, erzähle ich ausführlicher in Bilder konvertieren ohne Upload.

Die restlichen Tools decken einzelne, kleinere Probleme ab, auf die ich im Alltag immer wieder gestoßen bin. Ein Farbkontrast-Checker prüft WCAG-Pass-oder-Fail bei zwei beliebigen Farben, eine HTML-Vorschau ist eine abgeschottete Sandbox und ein JSON-LD-Generator baut strukturierte Daten. Dazu kommen ein LinkedIn-Text-Formatierer, weil LinkedIn kein Rich Text kennt und Fett sowie Kursiv dort nur über Unicode-Tricks funktionieren, sowie ein Meta-Tag-Checker mit Live-Vorschau der Google-Suche. Der Thumbnail Generator baut Social-Bilder, seine eigene Geschichte steht in Thumbnails erstellen ohne Canva. Und ein UTM-Parameter-Generator warnt schon beim Eintippen vor gängigen GA4-Tracking-Fehlern.

Keins davon ist eine Plattform. Es sind einzelne Werkzeuge, die ich gebaut habe, weil ich sie selbst gebraucht hab. Die kostenlosen Alternativen, die ich dazu im Netz fand, waren entweder vollgestopft mit Werbung, oder sie haben die eigentliche Arbeit auf einem fremden Server erledigt. Was das für die eigenen Daten heißt, steht ausführlicher in Bilder konvertieren ohne Upload.

Nichts, was du eintippst oder hochlädst, verlässt deinen Browser

Diese eine Design-Entscheidung zieht sich durch alle zwölf Tools. Jedes davon arbeitet clientseitig, in JavaScript, das direkt in deinem Tab läuft, nicht auf einem Backend, das ich irgendwo betreibe.

Das ist eine echte technische Einschränkung, kein Marketing-Argument für Privatsphäre. Wie stark sie das Bauen tatsächlich verändert, zeigt sich bei zwei Tools besonders deutlich. Der Bildkonverter dekodiert eine Kamera-RAW-Datei per WebAssembly lokal, statt sie an eine Konvertierungs-API zu schicken. Und der Thumbnail Generator rechnet das Layout und den PDF-Export komplett im Browser, statt serverseitig zu rendern. Beide Geschichten stehen für sich, ausführlich in Bilder konvertieren ohne Upload und Thumbnails erstellen ohne Canva. Der gemeinsame Nenner bleibt bei allen zwölf gleich: Es gibt keinen Server, der deine Daten protokollieren oder ausfallen könnte, weil keiner in der Kette hängt.

Wie ich das gebaut habe

Alle zwölf Tools zusammen kommen auf rund 4.000 Zeilen Komponenten-Code und 84 Tests. Entstanden ist das zwischen Ende Mai und Ende Juli 2026, nebenher zu allem anderen, was in der Zeit sonst noch lief.

Gebaut hab ich sie mit Claude Code, einem KI-Coding-Agenten, so wie ich mittlerweile die meisten Dinge baue. Ich hab die Arbeit angeleitet und jeden einzelnen Schritt geprüft, statt einfach abzunicken, was am Ende dabei rauskam. Ich bin kein professioneller App-Entwickler und hab fast keine Zeile Syntax selbst geschrieben. Was ich mitgebracht hab, war zu wissen, was jedes Tool genau können muss. Ich hab es gegen echte Eingaben getestet und Ergebnisse konsequent abgelehnt, die nicht standhielten. Denselben Ansatz hab ich schon beim Bau meines eigenen JLPT-Trainers und eines WordPress-Themes aus dem Nichts beschrieben.

Kleine, klar abgegrenzte Tools haben sich für diesen Workflow als guter Zuschnitt erwiesen. Jedes davon ist überschaubar genug, um es in einer einzelnen fokussierten Session zu bauen, zu testen und zu veröffentlichen. Dadurch wurden 84 Tests am Ende ein realistisches Ziel, keine nachträgliche Idee, die man sich nur noch schnell vornimmt.

Der Code liegt jetzt in einem öffentlichen Repo

Das ist der Teil, der diese Woche neu dazugekommen ist. Die Tools stecken in meinem privaten Website-Repo, demselben Code, der auch diesen Blog betreibt. Sie als Open Source zu veröffentlichen bedeutete deshalb, erst einen Weg zu finden, die Tools zu teilen, ohne dabei den Rest des Repos offenzulegen.

Die Lösung ist ein Export-Skript, das nur in eine Richtung läuft. Das private Website-Repo bleibt die einzige Quelle der Wahrheit. Das öffentliche Repo unter github.com/erichinzpeter/free-web-tools wird daraus automatisch erzeugt und nie von Hand bearbeitet. So können die beiden nicht auseinanderdriften, wie es bei einem manuell gepflegten Fork über kurz oder lang fast immer passiert.

Das öffentliche Repo spiegelt die Ordnerstruktur der Website exakt, Dateien kopieren sich also byteweise, ohne dass dazwischen irgendetwas umgeschrieben wird. Das heißt auch: Die Testsuiten der Tools wandern unverändert mit und laufen im öffentlichen Repo genauso durch wie im privaten, alle 84 davon.

Der Lizenzfund beim ersten Export

Der erste Durchlauf des Export-Skripts hat einen echten Fund gebracht. Die Headline-Schrift des Thumbnail Generators war bis dahin Righteous, und deren Open Font License reserviert den Namen „Righteous“ ausdrücklich für die originale, unveränderte Schrift.

Eine gekürzte Kopie davon unter genau diesem Namen in ein öffentliches Repo zu packen, hätte diese Lizenz verletzt, und zwar still und leise. Das wäre in einem Repo passiert, das eigentlich meine eigene Arbeit zeigen soll.

Der Fix war einfach, sobald ich das Problem gesehen hatte. Ich hab die Headline-Schrift gegen Anton getauscht, die keine solche Einschränkung trägt. Es ist eine kleine Änderung, die nichts daran ändert, was das Thumbnail-Tool tut. Aber genau diese Art Prüfung macht den Unterschied zwischen „läuft auf meinem Rechner“ und „sicher genug, um es jemand anderem in die Hand zu geben“.

Warum überhaupt öffentlich machen

Keines der zwölf Tools musste öffentlich sein, um nützlich zu sein. Das waren sie schon vorher, hinter ihren eigenen Seiten unter eric-hinzpeter.de/tools.

Was das Repo zusätzlich bringt, ist Einblick. Du kannst jetzt nachlesen, wie ein RAW-Decoder in den browserbasierten Bildkonverter eingebunden ist oder wie ein WCAG-Kontrastcheck gerechnet wird, statt es mir einfach zu glauben.

Willst du eines der Tools nutzen? Es ist schon da, ohne Umwege. Willst du sehen, wie es unter der Haube funktioniert, oder dir ein Stück davon für dein eigenes Projekt ausleihen? Dafür ist das Repo jetzt auch da. Was fehlt dir noch in der Liste? Schreib mir auf LinkedIn.