Öffne die Entwicklertools deines Browsers mit F12, wechsle zum Netzwerk-Tab und leere ihn. Ziehe dann deine Datei in das Tool und starte den Vorgang. Beobachte die Anfragen, die erscheinen: Wenn keine davon deine Datei trägt und die Größe jeder Anfrage weit kleiner ist als die Datei, wurde nichts hochgeladen.
Zwei weitere Tests bestätigen es. Trenne deine Verbindung, nachdem das Tool einmal geladen wurde, und versuche es erneut: Ein lokales Tool arbeitet weiter, ein serverbasiertes nicht. Sieh dir dann an, mit welchen Domains die Seite spricht, denn ein Dateiupload ist eine Anfrage an einen bestimmten Endpunkt und seine Größe ist proportional zu deinem Dokument. Die folgenden Abschnitte geben die genauen Schritte, und die Anfragen, die alarmierend aussehen, aber nur Code oder Seiten-Tracking sind. Keiner dieser Checks braucht Software über den Browser hinaus, den du bereits geöffnet hast.
Eine Datenschutzbehauptung auf einer Tool-Seite ist genau so viel wert wie deine Fähigkeit, sie zu prüfen. Die gute Nachricht ist, dass die Prüfung kurz ist, keine spezielle Software braucht und in jedem Browser funktioniert. Du suchst kein Versprechen. Du suchst eine ganz bestimmte Sache: eine Anfrage, die deine Datei trägt.
Bild-Kompressor
Ein sauberes Testobjekt: Lade ein Bild, beobachte das Panel, trenne dann die Verbindung und komprimiere ein weiteres. In beiden Fällen wird nichts hochgeladen.
Test eins: die Bytes im Netzwerk-Panel beobachten
Das ist die primäre Methode, und sie dauert etwa eine Minute. Du prüfst, ob eine Anfrage eine Nutzlast von ungefähr der Größe deiner Datei trägt.
- Die Entwicklertools öffnen. Drücke F12 oder verwende das Browsermenü und wähle Entwicklertools. Wechsle zum Netzwerk-Tab.
- Die Liste leeren. Klicke auf die Löschen-Schaltfläche, meist ein Kreis mit einem Strich durch. Das entfernt die Seitenressourcen, sodass nur die Anfragen deiner Dateiaktion übrig bleiben.
- Aktiviere Protokoll beibehalten, wenn du ein vollständiges Bild willst. Es hält Anfragen über ein Neuladen der Seite hinweg sichtbar, was hilft, wenn ein Tool mitten im Vorgang navigiert oder aktualisiert.
- Ziehe deine Datei hinein und führe das Tool aus. Verwende eine Datei mit markanter Größe, idealerweise ein paar Megabyte, damit eine passende Anfrage offensichtlich ist.
- Beobachte die Größe-Spalte. Jede Anfrage wird mit ihrer übertragenen Größe aufgeführt. Lies die größte. Ist die größte Anfrage ein Skript, eine Schrift oder ein kleiner Tracking-Aufruf, hat sich die Datei nie bewegt.
- Klicke auf die größte Anfrage und lies ihre Details. Die Tabs Headers, Payload und Size sagen dir, was gesendet wurde. Ein echter Upload erscheint als Anfrage, deren Größe ungefähr deiner Dateigröße entspricht.
Wonach du suchst, hat eine bestimmte Signatur. Ein Upload ist meist eine POST-Anfrage an einen Endpunkt wie /upload oder /convert, und ihre Größe ist nahe der Größe der Datei. Ist die Anfrage ein Formular, ist der Inhaltstyp wahrscheinlich multipart/form-data. Wird die Datei als Rohbytes oder base64 gesendet, ist der Inhaltstyp der der Datei selbst, oder die Nutzlast ist ein JSON-Body, der die Daten enthält. In allen drei Fällen verrät die Größe es, und deshalb ist die Größe-Spalte die, die du zuerst liest.
PDF entsperren
Ein sensibler Fall, der einen Test wert ist. Das PDF und das Passwort werden beide im Tab gelesen, das Panel zeigt also keine Anfrage, die eines von beiden trägt.
Test zwei: die Verbindung trennen und weiterarbeiten
Der Offline-Test beantwortet eine andere Frage, und er ist schwerer zu fälschen. Wenn die Verarbeitung ganz ohne Netzwerk trotzdem abgeschlossen wird, kann kein Server an der Arbeit beteiligt sein.
- Lade zuerst das Tool und verarbeite eine Datei. Das speichert die benötigte Engine zwischen, was ein normaler Download von Code ist und nicht deine Datei.
- Die Verbindung zum Netzwerk trennen. Schalte Wi-Fi aus, zieh das Kabel oder nutze das Netzwerk-Drosselungsmenü in den Entwicklertools und stelle es auf Offline.
- Verarbeite eine weitere Datei, ohne die Seite neu zu laden. Lade nicht neu, denn ein Neuladen muss die Seite selbst abrufen und wird aus Gründen scheitern, die nichts mit einem Upload zu tun haben.
- Beobachte das Ergebnis. Ein lokales Tool erzeugt seine Ausgabe. Ein serverbasiertes Tool scheitert, meist mit einem Netzwerkfehler in seiner Statuszeile.
Die Reihenfolge dieser Schritte ist der ganze Trick. Wenn du zuerst die Verbindung trennst und neu lädst, testest du den Seitenabruf, nicht die Verarbeitung. Und wenn du das Tool nie ausgeführt hast, bevor du offline gegangen bist, kann ein Scheitern einfach bedeuten, dass die Engine noch nicht zwischengespeichert war. Führe einen Auftrag online aus, zieh die Verbindung, führe einen zweiten Auftrag aus.
Test drei: die Domains und die Sicherheitsrichtlinie ansehen
Wohin eine Seite Daten sendet, ist genauso aufschlussreich wie wie viel. Im Netzwerk-Panel kannst du nach Domain sortieren oder filtern, und die Domains, die ein lokales Tool berührt, sind langweilig: sein eigener Host, ein Schrift- oder Skript-Host und möglicherweise ein Analytics-Anbieter. Ein Konverter, der auf einem Server läuft, muss seinen eigenen Upload-Endpunkt erreichen, und dieser Endpunkt erscheint meist auf derselben Domain wie die Seite.
Ein strengeres Signal ist der Content-Security-Policy-Header, den du im Headers-Tab der Hauptdokument-Anfrage lesen kannst. Eine Richtlinie mit einer engen connect-src-Direktive benennt die genauen Origins, die die Seite aufrufen darf, was einschränkt, wohin eine Datei selbst theoretisch gehen könnte. Ihr Fehlen beweist nichts, weil viele Seiten schlicht keine setzen. Kombiniere sie mit den Netzwerkbeweisen, statt sie als Test für sich zu behandeln.
Was verdächtig aussieht, aber keines ist
Die meisten Fehlalarme stammen aus vier Arten von Anfragen. Sie zu kennen bewahrt dich davor, ein sauberes Ergebnis als Leck fehlzudeuten.
- Analytics und Tag-Manager. Ein Seitenaufruf wird an einen Messdienst gemeldet, weshalb du ein Skript von einer Analytics-Domain siehst. Es trägt die Tatsache, dass eine Seite geladen wurde, nicht den Inhalt deines Dokuments. Diese Seite lädt Google Tag Manager, du wirst also genau diese Anfrage sehen.
- Engine-Downloads beim ersten Laden. Ein Browser-Tool lädt seine Verarbeitungs-Engine beim ersten Mal, wenn du es benutzt. Diese Anfrage ist groß, was sie wie einen Upload aussehen lässt, aber sie ist für jeden Besucher gleich und ändert sich nicht mit deiner Datei. Die Größe bleibt konstant, während sich deine Eingabe ändert.
- Schriften und Icons. Schriftarten und Icon-Sprites sind separate Dateien und erscheinen als eigene Anfragen. Sie sind meist höchstens ein paar hundert Kilobyte groß.
- Cross-Origin-Isolations-Header. Manche WebAssembly-Tools benötigen COOP- und COEP-Header für mehrthreadige Arbeit. Sie zu sehen ist ein Zeichen, dass eine echte Engine in der Seite läuft, kein Zeichen, dass deine Datei sich bewegt. Die Tools auf dieser Seite nutzen eine einthreadige Engine und brauchen sie nicht.
Die Trennlinie ist einfach. Code und Seitenressourcen haben Größen, die gleich bleiben, egal was du hochlädst. Deine Datei hat eine Größe, die nur dann auf der Leitung erscheint, wenn sie tatsächlich gesendet wird. Vergleiche die Gesamtzahl der übertragenen Bytes mit der Größe deiner Eingabe, und die Antwort ist nicht mehrdeutig.
Wo diese Methode Grenzen hat
Die obigen Tests sind stark, und sie sind nicht absolut. Klarheit über die Lücken ist das, was den Rest der Seite vertrauenswürdig macht.
- Chunking versteckt einzelne Zeilen, nicht die Summe. Ein Tool könnte eine Datei in viele kleine Anfragen aufteilen. Die Gesamtzahl der übertragenen Bytes zu zählen, durchkreuzt das, weshalb der Größenvergleich wichtiger ist als jede einzelne Zeile.
- Ein Service Worker kann ein Offline-Scheitern maskieren. Wenn eine Seite ihre eigenen Seiten zwischenspeichert, kann ein Offline-Neuladen trotzdem funktionieren. Der Offline-Test ist nur dann zuverlässig, wenn du das Neuladen vermeidest und dich stattdessen auf einen abgeschlossenen Auftrag verlässt.
- Datenverkehr kann verschlüsselt und undurchsichtig sein. Über HTTPS kannst du den Inhalt einer Anfrage nicht lesen, nur ihre Größe und ihr Ziel. Die Größe reicht aus, um einen Dateiupload zu erkennen, aber sie sagt dir nicht, was eine kleine Anfrage enthält.
- Lokal bedeutet nicht automatisch sicher. Die Verarbeitung im Tab schließt einen Upload aus. Sie sagt nichts über andere Risiken, etwa eine Seite, die in einem späteren Schritt mehr von deiner Festplatte liest. Prüfe die konkrete Behauptung, statt überall gutes Verhalten anzunehmen.
- Manche Tools brauchen wirklich einen Server. Große Modelle für Hintergrundentfernung oder generative Verbesserung passen nicht in ein Browser-Download-Budget, und diese Tools sagen das auch. Das ehrliche Muster ist eine Seite, die dir sagt, welche ihrer Funktionen hochladen und welche nicht, wie es der Cloud AI-Abschnitt hier tut.
Wenn du die zugrunde liegende Erklärung willst, warum ein Tab diese Arbeit überhaupt erledigen kann, behandelt der begleitende Leitfaden zu wie browserbasierte Datei-Tools funktionieren geht durch die Engine-, Canvas- und File API-Schichten. Wenn du nur ein Tool zum Testen willst, funktioniert jede Seite im Tool-Verzeichnis funktioniert, und PDF zusammenfügen ist ein gutes zweites Testobjekt, weil die Ein- und Ausgabegrößen leicht zu vergleichen sind.