Cron-Parser, Base64, JSON-Formatter, URL-Kodierung und acht weitere. Alles wird im Browser berechnet, nichts von dem, was du einfügst, erreicht unseren Server.
Wir haben gerade eine Handvoll kleiner Helfer unter /tools veröffentlicht: einen Parser für Cron-Ausdrücke, der die nächsten fünf Läufe zeigt, Base64-Kodierung, einen JSON-Formatter, Prozentkodierung für URLs und acht weitere. Sie sind kostenlos, brauchen kein Konto, und mitten drin wartet keine Verkaufsseite.
Das Interessante ist nicht, was sie tun. Interessant ist, wo sie es tun.
Keines dieser Tools schickt irgendetwas irgendwohin. Der Cron-Ausdruck, den du einfügst, das JSON, das du gerade debuggst, der Base64-Block, der vielleicht ein Token ist: alles verarbeitet JavaScript in deinem Browser, und nichts davon verlässt ihn. Es gibt keine Anfrage an unser Backend, weil auf diesem Weg gar kein Backend beteiligt ist.
Das klingt nach einer technischen Fußnote. Ist es nicht. Denk daran, was Leute tatsächlich in Online-Formatter einfügen: Datenbank-Zugangsdaten in einer JSON-Konfiguration, einen API-Schlüssel in einem Webhook-Payload, ein JWT direkt aus dem Produktions-Log. Jeder Dienst, der das serverseitig verarbeitet, hat diese Daten im Request-Log, ob er wollte oder nicht.
Wir hätten sie lieber nicht. Fremde Geheimnisse zu verwalten ist eine Haftung, für die wir nichts bekommen.
Die Tools nutzen nur, was der Browser ohnehin mitbringt: TextEncoder für UTF-8, btoa für Base64, JSON.parse, encodeURIComponent. Der Cron-Parser sind rund hundert Zeilen, von Hand geschrieben.
Auch das war eine bewusste Entscheidung. Ein Tool, das mit “läuft lokal” wirbt und dabei ein Skript aus dem CDN eines Dritten nachlädt, ist genau so lokal, wie der Betreiber dieses CDN es zulässt. Die Abhängigkeit verschwindet nicht dadurch, dass sie bequem ist.
Die eine Ausnahme, klar gesagt: diese Seiten tragen unsere Analytics, wie der Rest der Website. Sie zählt Seitenaufrufe. Sie sieht nicht, was du in die Tools eingibst, und kein Feldinhalt wird jemals übertragen.
Ehrliche Antwort: weil Leute danach suchen. Wer um zwei Uhr nachts einen crontab-Eintrag schreibt und auf */5 * * * * starrt, um zu prüfen, ob er richtig gerechnet hat, ist genau die Person, die nächste Woche wissen will, ob dieser Job wirklich gelaufen ist.
Die weniger zynische Antwort: wir schauen den ganzen Tag auf Cron-Ausdrücke. Der Parser zeigt das, was wir selbst sehen wollen, nämlich die nächsten fünf Läufe in deiner Zeitzone, und keinen Absatz Prosa, der dir deinen eigenen Zeitplan zurückerzählt. Wer einmal auf die Verwechslung von UTC und Ortszeit hereingefallen ist, weiß, warum das mehr zählt als die Formulierung.
Zwölf Stück: Cron-Parser, Base64, JSON-Formatter, URL-Kodierung, Timestamp-Konverter, UUID- und ULID-Generator, SHA-Hashing, Regex-Tester, chmod-Rechner, CIDR-Rechner, Passwortgenerator und eine schlichte Referenztabelle der HTTP-Statuscodes.
Die letzte enthält kein Gramm JavaScript, und die Tabelle hat eine Spalte, die die zwanzig anderen dieser Art im Netz nicht haben: was jeder Code für einen Monitor bedeutet. Ein 401 heißt meist, dass dein Check seine Zugangsdaten verloren hat, und nicht, dass der Dienst am Boden liegt. Ein 429 heißt, der Dienst lebt und weist ausgerechnet dich ab.
Und falls du dich irgendwann fragst, ob der Cron, den du gerade geschrieben hast, heute Nacht wirklich losgelaufen ist: das machen wir auch. Dafür braucht es dann ein Konto.
Registrieren, API-Schlüssel holen, curl in deinen Cron einfügen. Das war's.