← Alle Beiträge

So überprüfst du, ob ein Web-Tool deine Dateien wirklich nicht hochlädt (DevTools-Anleitung)

2026-05-30

Kurze Antwort: Öffne die DevTools des Browsers, wechsle auf den Tab Network (Netzwerk), leere ihn und lass dann das Tool eine Datei verarbeiten. Wenn die Datei deinen Browser nie verlässt, siehst du den Code des Tools herunterladen — aber du siehst die Bytes deiner Datei nicht hochladen. Hier die 60-Sekunden-Version, plus wie du das Gesehene liest.

Warum „wir speichern deine Dateien nicht" nicht reicht

Die meisten „kostenlosen" Online-Datei-Tools laden deine Datei auf einen Server, verarbeiten sie dort und schicken das Ergebnis zurück. Ihre Datenschutzerklärung verspricht vielleicht, sie danach zu löschen — aber das ist ein Versprechen, das du nicht prüfen kannst. „Wir speichern deine Dateien nicht" heißt trotzdem, dass deine Datei übertragen wurde und entschlüsselt auf der Maschine eines anderen lag. Eine Garantie, die du nicht überprüfen kannst, ist kein Datenschutz; sie ist Marketing.

Die gute Nachricht: Moderne Browser können die eigentliche Arbeit selbst erledigen — Bildverarbeitung, PDF-Rendering, Videokodierung über WebAssembly, sogar neuronale Netze über WebGPU. Wenn ein Tool lokal läuft, wird deine Datei in den Speicher des Browser-Tabs gelesen, verarbeitet und dir als Download zurückgegeben. Sie berührt das Netzwerk nie. Und anders als ein Versprechen kannst du das in unter einer Minute selbst bestätigen.

Der 60-Sekunden-Check (Tab Network)

  1. Öffne das Tool in einem neuen Tab (zum Beispiel Bild komprimieren oder Bild zu Text).
  2. Öffne die DevTools — drücke F12, oder Rechtsklick → Untersuchen. (Cmd+Opt+I auf dem Mac, Ctrl+Shift+I unter Windows und Linux.)
  3. Klick auf den Tab Network (Netzwerk).
  4. Klick auf das Leeren-Symbol (🚫), um vorhandene Anfragen zu löschen, und hake Preserve log (Log behalten) an, damit nichts verschwindet.
  5. Zieh jetzt deine Datei ins Tool und führ es aus.
  6. Sieh dir die Anfrageliste an und sortiere nach Size (Größe).

Worauf du achtest: Eine Anfrage, die deine Datei hochlädt, ist ein POST (oder PUT) mit einem Anfrage-Body etwa in der Größe deiner Datei. Lädst du ein 5-MB-Foto hoch, würdest du eine ~5-MB-Nutzlast nach draußen gehen sehen. Wenn die einzigen großen Übertragungen der eigene Code des Tools und .wasm-Dateien sind, die hereinkommen — und nach dem ersten Lauf aufhören, weil sie im Cache sind —, ist deine Datei geblieben, wo sie war.

So unterscheidest du einen Upload von normalem Verkehr

Nicht jede Anfrage ist ein Warnsignal. Das ist selbst bei einem 100% lokalen Tool normal:

  • Code und Assets laden — JavaScript-Bundles, .wasm-Binaries (FFmpeg, Tesseract und Co.), Schriften, die Seite selbst. Das sind Downloads: Die Antwort hat eine Größe, der Anfrage-Body ist leer, und sie werden nach dem ersten Besuch gecacht.
  • Analytics und Werbung — kleine Pings an Google Analytics oder AdSense. Winzig, und sie enthalten nie deine Datei (können sie nicht — deine Datei ist in keiner Variable, die sie erreichen).

Das ist ein Warnsignal:

  • Ein POST/PUT, dessen Nutzlast (Payload) etwa die Größe deiner Datei hat. Öffne den Tab Payload/Request dieser Anfrage, und du siehst buchstäblich die Bytes oder ein Multipart-Formular mit deinem Dateinamen.
  • Ein Upload zu einer unerwarteten Storage-Domain (einem S3-Bucket, irgendeinem CDN) genau in dem Moment, in dem du auf „verarbeiten" klickst.

Faustregel: Downloads kommen rein, keine großen Uploads gehen raus = lokale Verarbeitung.

Die radikale Option: Stecker ziehen

Wenn du gar keine Anfrage-Logs lesen willst, gibt es einen gröberen Test, den jeder machen kann:

  1. Lade die Tool-Seite einmal, damit ihr Code heruntergeladen wird.
  2. Schalte den Flugmodus ein / das WLAN aus — oder stell in den DevTools das Network-Throttling-Dropdown auf Offline.
  3. Führ das Tool aus.

Wenn es offline weiterhin funktioniert, kann es deine Datei physisch nicht hochladen: Es gibt keine Verbindung, über die es hochladen könnte. (Ein paar Tools holen bei Bedarf eine große Engine-Datei — manche Video-Tools laden FFmpeg beim ersten Mal. Lass diesen einen Download fertig werden, geh dann offline und verarbeite.)

Warum laden dann so viele Tools hoch?

Ehrlich gesagt, weil die Server-Seite leichter zu monetarisieren ist. Hochladen erlaubt einer Firma, Funktionen hinter ein Abo zu sperren, Nutzung zu protokollieren und — im schlimmsten Fall — deine Dateien zum Trainieren von Modellen zu behalten. Lokale Verarbeitung erfordert mehr Engineering: C-Bibliotheken nach WebAssembly kompilieren, sie ins Speicherbudget des Browsers quetschen, diesen Hebel aufgeben. Der Tausch lohnt sich aus einem Grund — deine Dateien gehen nirgendwohin, und du musst mir nicht glauben. Du kannst auf den Network-Tab schauen.

Das ist die ganze Idee hinter ToolKoala: Jedes Tool läuft in deinem Browser. Öffne bei jedem davon die DevTools und überzeug dich selbst.

FAQ

Heißt „kein Upload", dass das Tool offline funktioniert? Nach dem ersten Laden meistens ja. Der Code ist gecacht, daher funktionieren die meisten Tools ohne Verbindung weiter. Ein paar, die bei Bedarf eine große Engine holen (manche Video-Tools), brauchen diesen einen Download zuerst.

Könnte ein Tool meine Datei heimlich über WebSockets oder im Hintergrund hochladen? Der Network-Tab zeigt auch WebSocket- und Hintergrund-fetch/XHR-Verkehr, inklusive Nutzlast. Wenn die Bytes deiner Datei rausgehen, tauchen sie dort auf. Genau das ist der Punkt: Ein Upload kann sich vor dem Network-Tab nicht verstecken.

Sind Analytics oder Werbung ein Datenschutzproblem? Sie sehen Standard-Besuchssignale — grober Standort, Gerätetyp —, nicht deine Datei. Deine Datei landet in keiner Variable, die ein Werbeskript erreicht, und wenn du sie blockierst, funktionieren die Tools trotzdem.

Gilt das nur für ToolKoala? Nein. Dieser Check funktioniert bei jedem Web-Tool. Mach ihn bei jedem „kostenlosen Online-Konverter", bevor du ihm eine sensible Datei anvertraust.

— Milo 🐨