Sicherheit bei gottrix

gottrix.app verarbeitet Dateien zu 100% lokal im Browser: Der Umwandlungs-Code hat per Content-Security-Policy keinerlei Zugriff auf fremde Server, ein Upload ist technisch ausgeschlossen. Die Auslieferung läuft über TLS 1.2/1.3 mit HSTS (2 Jahre), einem vollständigen Satz Sicherheits-Header und Hosting bei Hetzner in Deutschland. Jeder Punkt auf dieser Seite ist selbst nachprüfbar.

Null-Upload-Architektur: Sicherheit durch Wegfall

Übliche Online-Konverter laden deine Datei auf einen Server, verarbeiten sie dort und schicken das Ergebnis zurück - jeder dieser Schritte ist eine Angriffsfläche. gottrix lässt den kritischen Schritt komplett entfallen: Die Engines (etwa für Bilder, PDFs, Audio und Video) laufen als WebAssembly direkt in deinem Browser. Was nie übertragen wird, kann unterwegs nicht abgefangen, auf keinem Server geleakt und von niemandem herausverlangt werden.

Durchgesetzt wird das nicht per Richtlinie, sondern per Architektur mit zwei strikt getrennten Zonen: Der Code, der deine Datei-Bytes berührt (Engines und Web-Worker), ist per Content-Security-Policy auf die eigene Origin beschränkt und enthält null Netzwerk-Aufrufe - das prüft ein automatischer Test bei jedem Build. Die Seiten-Ebene, die deine Dateien nie sieht, darf ausschließlich eine dokumentierte Analytics-Allowlist erreichen.

Engines und Worker: 0 Netzwerk-Primitive, keine fremden Origins - statisch geprüft bei jedem Build.
Seiten-Ebene: fremde Requests nur an die dokumentierte Analytics-Allowlist, nie Datei-Bytes.
Kein Upload-Fallback: Schlägt die lokale Verarbeitung fehl, gibt es eine ehrliche Fehlermeldung - nie einen Server-Umweg.
Offline-Beweis: Nach dem ersten Besuch funktionieren die Tools auch im Flugmodus - der stärkste Beleg, dass nichts gesendet wird.

Datenfluss: von deinem Gerät bis zum Server

Jede Anfrage an gottrix.app läuft zunächst über das Cloudflare-Edge-Netzwerk, das die TLS-Verbindung terminiert und die Auslieferung beschleunigt, bevor sie an den Origin-Server bei Hetzner in Deutschland weitergeleitet wird. Cloudflare und Hetzner verarbeiten dabei ausschließlich technische Verbindungsdaten wie IP-Adresse, angefragte URL und Zeitstempel - nie Dateiinhalte, denn diese verlassen dein Gerät nicht. Beim freiwilligen Feedback-Formular kommen zwei weitere Zweige hinzu (Cloudflare Turnstile zur Bot-Abwehr, Resend für eine einzelne interne Benachrichtigung); die anonyme Nutzungs-Statistik läuft, nur mit deiner Einwilligung, direkt von deinem Browser zu Google Analytics 4. Die vollständige Empfängertabelle mit allen Datenkategorien und Rechtsgrundlagen steht weiter unten.

Empfänger deiner (Verbindungs-)Daten

Die folgende Tabelle listet jeden externen Empfänger, der beim Betrieb von gottrix.app technische Daten verarbeitet - erzeugt aus demselben Register wie die Datenschutzerklärung, damit beide Seiten nie auseinanderlaufen. Deine Datei-Inhalte stehen in keiner Zeile, weil sie keinen dieser Empfänger erreichen.

Empfänger deiner (Verbindungs-)Daten
Empfänger	Rolle	Sitz	Datenkategorien	Rechtsgrundlage	Transfermechanismus	Aufbewahrung
Hetzner Online GmbH	Origin-Hosting / Server-Zugriffslogs	Deutschland	Gekuerzte/maskierte IP-Adresse (im Caddy-Zugriffslog, GDPR-uebliche Truncation: IPv4 auf /24 = letztes Oktett genullt, IPv6 auf /48 = letzte 80 Bit genullt; Details siehe evidence); Zeitstempel; angefragte URL; User-Agent; HTTP-Statuscode; Feedback-Freitext + optionale Diagnosedaten (Browser/Plattform/Viewport/Client-Zeit) in der Feedback-DB, KEINE IP-Adresse und KEINE E-Mail-Adresse (laut Tabellenschema bewusst keine Spalte dafuer)	Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse am sicheren, stabilen Betrieb; fuer Feedback: berechtigtes Interesse an Missbrauchsschutz/Bearbeitung, optionale Diagnosedaten Art. 6 Abs. 1 lit. a DSGVO)	keine Drittlanduebermittlung (Sitz Deutschland/EU)	90 Tage
Cloudflare, Inc.	CDN / Reverse Proxy / Bot-Abwehr (inkl. Turnstile fuer das Feedback-Formular)	USA	IP-Adresse (jeder Request, da Cloudflare TLS terminiert - nicht auf das Feedback-Formular beschraenkt); angefragte URL; User-Agent; Zeitstempel; TLS-/Verbindungsmetadaten; NEL-Fehlerberichte (Netzwerkfehler-Metadaten des Browsers); Turnstile-Challenge-Antwort-Token + optional die Besucher-IP als remoteip-Parameter (nur beim Absenden des Feedback-Formulars)	Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an sicherer, performanter Auslieferung und Missbrauchs-/Bot-Abwehr)	EU-Standardvertragsklauseln, ggf. EU-US Data Privacy Framework (konkrete Cloudflare-Vertragsgrundlage im Repository nicht dokumentiert - zu verifizieren, siehe offene Punkte)	nicht konkret ermittelbar
Google Ireland Ltd.	Web-Analytics (Google Analytics 4, Consent Mode v2 Advanced)	Irland (moegliche Weiterverarbeitung/Uebermittlung an Google LLC, USA)	gekuerzte IP-Adresse; Seiten-URL; Ereignis-/Werkzeug-Kennung; Zeitstempel; Geraete-/Browser-Metadaten (User-Agent)	Art. 6 Abs. 1 lit. a DSGVO i.V.m. § 25 Abs. 1 TDDDG (Einwilligung); vor Einwilligung ausschliesslich anonyme Modellierungssignale ohne Cookie und ohne Personenbezug	EU-Standardvertragsklauseln, EU-US Data Privacy Framework	nicht konkret ermittelbar
Resend, Inc.	Transaktionale E-Mail (genau eine interne Benachrichtigung pro Feedback-Eingang)	USA	Feedback-Freitext (im E-Mail-Body); optionale Werkzeug-Kennung, Seiten-Pfad, Sprache, Zeitstempel (im E-Mail-Body); optionale Diagnosedaten (Browser/Plattform/Viewport/Client-Zeit), NUR bei separater ausdruecklicher Einwilligung; KEINE Besucher-IP-Adresse, KEINE Besucher-E-Mail-Adresse (laut Code nicht Teil der API-Payload)	Art. 6 Abs. 1 lit. f DSGVO (berechtigtes Interesse an Bearbeitung des Anliegens); fuer optionale Diagnosedaten Art. 6 Abs. 1 lit. a DSGVO (gesonderte Einwilligung)	EU-Standardvertragsklauseln, soweit einschlaegig EU-US Data Privacy Framework	in der Regel 180 Tage

Aufbewahrungsfristen im Überblick

Alle bei gottrix.app bekannten Aufbewahrungsfristen an einem Ort, konkret statt pauschal:

Aufbewahrungsfristen im Überblick
Server-Zugriffslogs (Hetzner, Origin)	90 Tage
Feedback-Einreichungen (Datenbank)	in der Regel 180 Tage
Google Analytics 4 (Nutzungsstatistik)	nicht konkret ermittelbar

Die Aufbewahrung von Google Analytics 4 wird in der Google-Analytics-Property konfiguriert, nicht im Quellcode von gottrix.app - der konkrete Wert ist von hier aus nicht nachprüfbar. Alle Rechtsgrundlagen stehen in der Datenschutzerklärung.

Transport: TLS und HSTS

Die Website wird ausschließlich über HTTPS ausgeliefert - TLS 1.2 und 1.3 mit modernen Cipher-Suites und automatisch verwalteten Zertifikaten. HTTP Strict Transport Security (HSTS) ist mit max-age=63072000 (2 Jahre) inklusive Subdomains gesetzt: Der Browser erzwingt HTTPS damit auch bei allen künftigen Besuchen von sich aus. Zur Einordnung: Deine Datei-Inhalte durchlaufen diese Verbindung nie, denn sie verlassen dein Gerät nicht - die Transportverschlüsselung schützt die Auslieferung der Seite selbst.

HTTP-Sicherheits-Header

Jede Antwort des Servers trägt einen vollständigen Satz Sicherheits-Header. Die Werte sind kein Anspruch, sondern Konfiguration: Ein automatischer Test bricht jeden Deploy ab, bei dem einer fehlt oder abweicht.

HTTP-Sicherheits-Header
Header und Wert	Wirkung
Strict-Transport-Security: max-age=63072000; includeSubDomains	Erzwingt HTTPS für 2 Jahre, inklusive aller Subdomains.
X-Frame-Options: DENY	Kein Einbetten der Seite in fremde Frames (Clickjacking-Schutz, doppelt abgesichert über frame-ancestors in der CSP).
X-Content-Type-Options: nosniff	Verhindert, dass der Browser Inhaltstypen errät und Dateien als Skript ausführt.
Referrer-Policy: strict-origin-when-cross-origin	Gibt an fremde Seiten höchstens die Origin weiter, nie vollständige URLs.
Permissions-Policy: geolocation=(), usb=(), camera=(self), microphone=(self), ...	Deaktiviert 12 Geräte- und Sensor-APIs (Standort, USB, die Privacy-Sandbox-APIs Attribution-Reporting/Browsing-Topics/Interest-Cohort u. a.), die die Seite nicht braucht; nur Vollbildmodus, Bildschirmfreigabe, Kamera und Mikrofon (für die jeweiligen Aufnahme-Tools) bleiben der eigenen Origin erlaubt.
Cross-Origin-Opener-Policy: same-origin	Isoliert das Browserfenster von fremden Seiten, die es geöffnet haben.
Cross-Origin-Resource-Policy: same-origin	Verhindert, dass fremde Seiten Ressourcen dieser Origin einbetten oder auslesen.

Die Content-Security-Policy im Volltext

Die CSP ist die technische Sperre hinter der Null-Upload-Garantie. Sie wird aus einer einzigen Quelldatei erzeugt und hier live aus genau dieser Quelle gerendert - alle 17 Direktiven, ungekürzt:

default-src 'self'
script-src 'self' 'wasm-unsafe-eval' 'sha256-IVwTUmhRUWm+PlXmt9psO+ld19VPfQQW+7HvkcN0W1Y=' https://www.googletagmanager.com https://challenges.cloudflare.com
style-src 'self' 'unsafe-inline'
img-src 'self' data: blob: https://www.google-analytics.com https://*.google-analytics.com https://www.googletagmanager.com
media-src 'self' blob:
font-src 'self'
connect-src 'self' https://www.google-analytics.com https://*.google-analytics.com https://www.googletagmanager.com
worker-src 'self' blob:
frame-src 'self' blob: https://challenges.cloudflare.com
child-src 'self' blob:
object-src 'none'
base-uri 'none'
form-action 'self'
frame-ancestors 'none'
upgrade-insecure-requests
report-uri /api/csp-report
report-to csp-endpoint

Google CSP Evaluator (geprüft am 2026-07-09): 0 Befunde der Stufe High. connect-src erlaubt neben der eigenen Origin ausschließlich die dokumentierte Analytics-Allowlist der Seiten-Ebene - Metadaten, nie Datei-Inhalte.

Die bestehende Content-Security-Policy (default-src 'self') wirkt zugleich als technische Werbe-Sperre: Sie erlaubt dem ausgelieferten Code grundsätzlich keine Verbindung zu einer fremden Origin. Selbst ein versehentlich eingeschleustes Werbe- oder Tracking-Skript könnte dadurch nicht funktionieren - der Browser blockiert jede solche Verbindung anhand der Policy. Das ist keine Ankündigung, sondern eine im Quelltext nachprüfbare Eigenschaft der bestehenden Architektur.

Bewusste Entscheidung: Privacy-Sandbox-APIs bleiben blockiert

Die Permissions-Policy-Zeile oben blockiert browsing-topics=(), attribution-reporting=() und interest-cohort=() vollständig - das ist keine beiläufige Konfiguration, sondern eine bewusste, dauerhafte Entscheidung. Diese drei APIs sind Teil von Googles "Privacy Sandbox": Ersatzmechanismen für das klassische Tracking-Cookie, mit denen der Browser selbst Interessenprofile bilden oder Werbezuordnungen speichern könnte. Sie zu blockieren ist bei gottrix kein technisches Detail, sondern ein Differenzierungsmerkmal, konsequent zur Null-Upload-Architektur: Wo schon Datei-Inhalte den Browser nie verlassen, hat auch kein browserinternes Interessenprofil etwas verloren.

Werbenetzwerke

Stand 2026-07-25: gottrix bindet derzeit keine Werbenetzwerke ein. Sollte sich das ändern, wird es hier und in der Datenschutzerklärung vor der Umstellung ausgewiesen.

Unabhängige Überprüfung

Drei externe Prüfungen sind fest eingeplant und laufen zum öffentlichen Start gegen die Live-Domain: SSL Labs (TLS-Konfiguration), Mozilla Observatory (HTTP-Sicherheitslage) und securityheaders.com (Header-Vollständigkeit). Die Ergebnisse werden erst angezeigt und verlinkt, wenn die Scans tatsächlich gelaufen sind - gottrix zeigt grundsätzlich keine unverifizierten Siegel oder Noten, und genau das erzwingt ein automatischer Test in jedem Build.

Kein Upload100% lokal

Inhalte bleiben bei dirkein Zugriff durch Dritte

Hosted in GermanyGlobal Content Delivery

Extern geprüftTLS A+ · Header A+

Hosting und Datenstandort

Die Origin-Server stehen bei der Hetzner Online GmbH in Deutschland und unterliegen der DSGVO. Auf ihnen liegt ausschließlich die statische Website: keine Nutzerkonten, keine Datei-Inhalte, keine Inhalts-Datenbank. Server-Logs enthalten nur technisch notwendige Zugriffsdaten mit einer Aufbewahrungsdauer von 90 Tagen; ein Auftragsverarbeitungsvertrag mit Hetzner besteht. Da die Datei-Verarbeitung lokal im Browser stattfindet, erreichen deine Datei-Inhalte diesen Standort ohnehin nie.

Statistik und Einwilligung

Die anonyme Nutzungs-Statistik (Google Analytics 4 mit Consent Mode v2 Advanced) startet mit allen Signalen auf abgelehnt: Ohne deine Zustimmung wird kein Statistik-Cookie gesetzt und keine Kennung gebildet. Mit Zustimmung werden höchstens Seitenaufrufe und die Kennung des genutzten Werkzeugs gemessen - nie Dateinamen, Dateigrößen oder Datei-Inhalte. Alle Details und Rechtsgrundlagen stehen in der Datenschutzerklärung.

Zur Datenschutzerklärung

Hinweis für Unternehmen und Behörden

gottrix beendet eine Datenschutz- oder Sicherheitsprüfung, statt sie zu eröffnen: Weil Datei-Inhalte den Browser nie verlassen, entsteht für sie technisch keine Übertragung an uns - und ohne Übertragung keine Verarbeitung, die eine Prüfung überhaupt aufhalten könnte. Das gilt unabhängig davon, wer die Datei öffnet: Kanzlei, Praxis, Steuerbüro, Personalabteilung, Behörde oder Privatperson.

Für Dateiinhalte entsteht keine Auftragsverarbeitung, weil keine Übertragung stattfindet - es gibt keinen Verarbeitungsvorgang bei gottrix, den ein Vertrag regeln müsste. Für die Auslieferung der Website, die nur mit Einwilligung gemessene Nutzungs-Statistik und das getrennte Feedback-Formular ist der Betreiber Verantwortlicher, nicht Auftragsverarbeiter. Daraus folgt: Ein Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO ist für die Nutzung der Werkzeuge selbst weder erforderlich noch rechtlich passend - wir stellen deshalb bewusst kein AVV-Muster für Dateiverarbeitung bereit.

Diese Einschätzung bezieht sich ausdrücklich nur auf Datei-Inhalte. Für die Website-Auslieferung über Cloudflare und die Nutzungs-Statistik (Google Analytics 4) ist gottrix selbst datenschutzrechtlich Verantwortlicher, und für diese Dienste bestehen Auftragsverarbeitungsverträge mit den jeweiligen Anbietern (siehe die Datenschutzerklärung). Wer einen AVV für die Website-Ebene benötigt, findet die Vertragspartner dort - nur eben nicht für Dateiinhalte, weil es dafür keinen Verarbeitungsvorgang gibt, den ein AVV abdecken müsste.

Nach Berufsgruppe und Branche

Für 9 konkrete Berufsgruppen - von Kanzleien über Praxen, Steuerberatung, Betriebsräte und Behörden bis zu Schul-IT und Privatpersonen - haben wir die Auftragsverarbeitungs-Frage ausführlich eingeordnet, inklusive Quellenangaben und FAQ je Berufsgruppe.

Auftragsverarbeitung (AVV): Warum gottrix keinen braucht

Was gottrix nicht hat

Keine ISO-27001-Zertifizierung.
Kein SOC 2 (Type I oder II).
Kein Single Sign-On (SSO) oder Identitäts-Föderation für Unternehmenskonten.
Kein vertragliches Support-Service-Level-Agreement (SLA).

Diese Lücken sind bewusst offen benannt, nicht verschwiegen: Eine Prüfung, die an einer eingeräumten Lücke endet, ist ehrlicher als eine, die an einer entdeckten scheitert.

Kontakt für Datenschutzbeauftragte: info@gottrix.app

Verantwortungsvolle Offenlegung

Eine Schwachstelle gefunden? Wir freuen uns über verantwortungsvolle Meldungen. Bitte teste ausschließlich gegen dein eigenes Gerät bzw. deinen eigenen Browser, ohne Datenverlust, Serviceunterbrechung oder Zugriff auf fremde Nutzerdaten zu verursachen - bei der Null-Upload-Architektur von gottrix bedeutet das in der Praxis: CSP-Umgehungen, XSS, Header- oder TLS-Fehlkonfigurationen und ähnliche Web-Schwachstellen der ausgelieferten Seite selbst.

In gutem Glauben durchgeführte Tests nach dieser Policy führen zu keiner rechtlichen Verfolgung durch gottrix. Wir bestätigen den Eingang, priorisieren nach Schwere und halten dich über den Fortschritt auf dem Laufenden - aktuell als Solo-Projekt ohne festes Reaktionszeit-SLA, aber mit echtem Interesse an jeder Meldung.

Kontakt für Sicherheitsmeldungen: info@gottrix.app

Häufige Fragen zur Sicherheit

Ist gottrix.app sicher?

Die Sicherheit beruht auf Architektur statt Versprechen: Dateien werden ausschließlich lokal im Browser verarbeitet und nie an Server übertragen - eine strikte Content-Security-Policy verbietet dem Umwandlungs-Code jede fremde Verbindung. Dazu kommen TLS 1.2/1.3 mit HSTS, ein vollständiger Satz Sicherheits-Header und Hosting in Deutschland. Jeder dieser Punkte ist im Quelltext, im Netzwerk-Tab oder per Flugmodus-Test selbst nachprüfbar.

Werden meine Dateien hochgeladen oder gespeichert?

Nein. Die Umwandlung läuft komplett im Arbeitsspeicher deines Browsers; es existiert kein Upload-Endpunkt und kein Server-Speicher für Datei-Inhalte. Die Content-Security-Policy erlaubt dem Engine- und Worker-Code keinerlei Verbindung zu fremden Servern, und ein automatischer Test prüft das bei jedem Build. Schließt du den Tab, sind die Daten weg - es gibt nichts, was serverseitig gelöscht werden müsste.

Welche Verschlüsselung verwendet gottrix.app?

Die Website wird ausschließlich über HTTPS mit TLS 1.2 und 1.3 und modernen Cipher-Suites ausgeliefert; HSTS erzwingt HTTPS für zwei Jahre inklusive Subdomains. Deine Datei-Inhalte selbst durchlaufen dabei keine Verbindung, weil sie das Gerät nie verlassen - die Transportverschlüsselung schützt die Auslieferung der Seite und die optionalen, einwilligungsbasierten Nutzungs-Metadaten.

Wo werden die Server gehostet?

Die Origin-Server stehen bei der Hetzner Online GmbH in Deutschland, es gilt die DSGVO. Dort liegt ausschließlich die statische Website: keine Nutzerkonten, keine Datei-Inhalte, keine Inhalts-Datenbank. Da die Verarbeitung lokal in deinem Browser stattfindet, ist der Serverstandort für deine Datei-Inhalte ohne Bedeutung - sie erreichen ihn zu keinem Zeitpunkt.

Wie kann ich die Sicherheitsangaben selbst überprüfen?

Drei Wege ohne Spezialwissen: der Flugmodus-Test (Tool öffnen, Verbindung trennen, konvertieren - es funktioniert weiter), der Netzwerk-Tab der Entwicklertools (F12: kein Datei-Request beim Konvertieren) und die Response-Header, die jeder Browser anzeigt. Die Schritt-für-Schritt-Anleitung steht auf der Beweis-Seite; zum öffentlichen Start kommen externe Scans von SSL Labs, Mozilla Observatory und securityheaders.com dazu.

Welche Daten erfasst gottrix überhaupt?

Ohne deine Einwilligung: keine Statistik-Cookies und keine Kennungen, nur technisch notwendige Server-Logs mit einer Aufbewahrungsdauer von 90 Tagen. Mit Einwilligung misst Google Analytics 4 aggregierte Nutzung, etwa Seitenaufrufe und die Kennung des genutzten Werkzeugs; Dateinamen, Dateigrößen und Datei-Inhalte werden nie erfasst. Die vollständigen Rechtsgrundlagen und Widerrufswege stehen in der Datenschutzerklärung.

Nachprüfbarkeit: wie du das selbst kontrollierst

Jede Aussage auf dieser Seite lässt sich mit Bordmitteln selbst nachprüfen - vom Flugmodus-Test bis zum Netzwerk-Tab der Entwicklertools. Die vollständige Schritt-für-Schritt-Anleitung führt die Beweis-Seite. Das Prüf-Skript hinter dieser Garantie liegt offen im Quellcode dieses Projekts unter oss/gate-null-upload-static/ - zum Nachprüfen und zur Wiederverwendung.

So ist das nachprüfbar

Der technische Nachweis: Wie NULL-UPLOAD implementiert ist

Dieser Abschnitt richtet sich an Entwicklerinnen, Sicherheitsteams und alle, die prüfen wollen statt zu vertrauen. Er beschreibt, wie die lokale Verarbeitung tatsächlich im Code umgesetzt ist - mit konkreten Beispielen, dem Durchsetzungs-Mechanismus und den ehrlichen Grenzen des heutigen Stands. Nichts davon ist eine Zusage; alles davon ist nachprüfbar.

Zwei Zonen, eine Grenze

Der Code ist in zwei Zonen getrennt - nicht nur in der Dokumentation, sondern durchsetzbar im Build. Die erste Zone (die Umwandlungs-Engines, die Web-Worker-Pipeline, die Ausführungsschicht sowie die Rechenkerne der Online-Rechner) hält die Datei-Bytes: Sie liest sie ein, wandelt sie um, gibt sie zurück. Diese Zone darf laut Architektur überhaupt kein Netzwerk-Primitiv enthalten - kein fetch, kein XMLHttpRequest, kein sendBeacon, kein WebSocket, keine fremde Adresse als String-Literal.

Die zweite Zone ist die Seite selbst (Layout, Nutzungsmessung). Sie darf Netzwerk nutzen - aber ausschließlich für Nutzungsmetadaten (Seitenaufrufe, welches Werkzeug benutzt wurde) an eine feste Allowlist, nie für Dateiinhalte. Die Trennung ist absichtlich eng gezogen: Der Code, der mit einem Analyse- oder Werbenetzwerk sprechen darf, ist eine andere Codebasis als der, der jemals Deine Datei zu sehen bekommt.

Ein konkretes Beispiel aus der ersten Zone: Wird eine Datei abgelegt, liest der Browser sie über die Dateisystem-Schnittstelle in ein ArrayBuffer im Speicher der Seite. Dieses Byte-Feld wird per postMessage an einen Web Worker übergeben - einen zweiten Ausführungsstrang im selben Browser, gestartet als eigener Modul-Worker: new Worker(new URL('../workers/pipeline.worker.ts', import.meta.url), { type: 'module' }). Dort läuft der eigentliche Umwandlungscode.

Zwei Engines im Detail

Reines JavaScript: PDFs zusammenfügen

Das PDF-Zusammenfügen läuft über die Bibliothek pdf-lib - reines JavaScript, keine WebAssembly-Komponente. Seiten werden objektweise aus den Quelldateien in ein neues Dokument kopiert, nicht neu gerendert. Das Ergebnis kommt als Bytes aus dem Worker zurück, wird zu einem Blob und daraus zu einem Download-Verweis. Der gesamte Weg ist Arbeitsspeicher, dann Worker, dann wieder Arbeitsspeicher, dann Festplatte - an keiner Stelle steht eine Netzwerkverbindung.

WebAssembly: AVIF- und JXL-Bildcodecs

Andere Engines brauchen echte WebAssembly, weil der Browser diese Formate nicht nativ beherrscht - etwa die AVIF- und JXL-Kodierung über die jSquash-Codecs. Die WASM-Binärdateien werden beim Build als eigenständiger, gleich-originärer Dateiimport eingebunden: Der Bundler kopiert sie neben den restlichen Code, die Engine lädt sie von dort - nie von einer fremden Adresse. Ob eine Engine JavaScript, WebAssembly oder eine bedingte Mischung aus beidem nutzt, ist im Code selbst dokumentiert, nicht nur behauptet.

Die harte Durchsetzung: ein Quellcode-Scanner, kein Versprechen

Die Trennung wäre wertlos, wenn sie nur eine Konvention bliebe. Deshalb läuft vor jeder Veröffentlichung ein statischer Scanner über genau die Programmteile, in denen Datei-Bytes leben. Er lässt den Build fehlschlagen, sobald einer dieser Fälle auftaucht:

fetch(), XMLHttpRequest, navigator.sendBeacon, new WebSocket, EventSource, importScripts()
eine fremde Adresse als String-Literal (jede http(s)://-Zeichenfolge, außer einer Handvoll eng begründeter, nie abgerufener Ausnahmen wie XML-Namensraum-Konstanten)
eine Beacon-artige Zuweisung wie img.src = "https://..."
jeder Verweis auf ein Tracking-Skript (gtag(), googletagmanager, google-analytics) - diese dürfen ausschließlich im Seiten-Layer stehen, niemals dort, wo Datei-Bytes verarbeitet werden

Über die offensichtlichen Umwandlungs-Engines hinaus deckt der Scanner auch die Rechenkerne der Online-Rechner, die Interaktions-Module und jede Hilfsbibliothek ab, die in diese Zonen eingebunden wird - nicht nur die Dateien, die wie eine Engine aussehen. Eine zweite, unabhängige Prüfung liest die ausgelieferte Content-Security-Policy: Sie erlaubt Netzwerkverbindungen ausschließlich zur eigenen Herkunft plus einer kurzen, namentlich genannten Analyse-Allowlist - jede andere Adresse wäre ein Regelverstoß, den der Browser selbst blockiert, unabhängig vom Quellcode.

Die Content-Security-Policy als zweite, browserseitige Schranke

Selbst wenn der Quellcode-Scanner eine neue Netzwerkstelle übersehen würde, greift eine zweite, vom Browser selbst durchgesetzte Schranke: Die ausgelieferte connect-src-Direktive erlaubt nur die eigene Herkunft und drei namentlich genannte Analyse-Adressen. Jede andere Zieladresse wird vom Browser blockiert, bevor die Anfrage das Gerät verlässt - unabhängig davon, was der Code versucht:

connect-src 'self' https://www.google-analytics.com https://*.google-analytics.com https://www.googletagmanager.com

Selbst nachprüfen, ohne uns zu vertrauen

Entwicklerwerkzeuge öffnen (F12), Reiter Netzwerk. Eine Umwandlung starten und die Liste beobachten: Es erscheint keine Anfrage, die Deine Datei überhaupt enthalten könnte - nur Seitenbestandteile, die schon vor der Umwandlung geladen waren.
Internetverbindung trennen (Flugmodus) und die Umwandlung erneut ausführen. Bei der großen Mehrheit der Werkzeuge funktioniert sie unverändert weiter - der stärkste Beleg, weil ein serverseitig rechnender Anbieter diesen Test grundsätzlich nicht bestehen kann.
Die ausgelieferte Sicherheitsrichtlinie direkt einsehen: im Antwort-Header Content-Security-Policy einer beliebigen Anfrage an die Seite, oder über ein öffentliches CSP-Analyse-Werkzeug. Die connect-src-Zeile ist der oben zitierte, kurze Text - nicht mehr.
Den Reiter Anwendung, dann Service Worker prüfen: Nach dem ersten Laden zeigt er einen aktiven Worker mit eigenem Zwischenspeicher - das ist der Mechanismus, der Offline-Nutzung überhaupt erst ermöglicht (mehr dazu unten).

Der Offline-Test - und seine ehrlichen Grenzen

Nach dem ersten Seitenaufruf lädt ein Service Worker im Hintergrund die für das jeweilige Werkzeug nötigen Programmteile vor, während die Verbindung noch besteht. Wird die Verbindung danach getrennt, funktioniert die große Mehrheit der Werkzeuge unverändert weiter - einschließlich einer vollständigen Umwandlung. Das ist kein Nebeneffekt, sondern der direkte Beweis: Ein Dienst, der Deine Datei auf einem Server verarbeitet, kann diesen Test nicht bestehen.

Was beim allerersten Offline-Versuch heute noch NICHT funktioniert

Zehn Umwandlungs-Engines mit besonders großen Programmteilen (unter anderem HEIC-Umwandlung, AVIF/JXL-Kodierung und mehrere PDF-Analyse-Werkzeuge) liegen über der Größengrenze, bis zu der vorab geladen wird - zusammen betreffen sie mehr als zehn einzelne Werkzeug-Seiten. Ein Vorab-Laden für alle wäre für die große Mehrheit, die nie umwandelt, unnötiger Datenverbrauch.
Die visuellen PDF-Editoren laden ihre Vorschau über ein größeres Anzeige-Modul, das ebenfalls nicht vorab zwischengespeichert wird.
Rund 47 Werkzeuge laden ein großes Zusatzmodul (Video-/Audio-Kodierung, Spracherkennung, Texterkennung) erst im Moment der ersten Nutzung nach, nicht vorab - das lässt sich mit keiner Vorlade-Strategie sinnvoll vereinbaren.
In allen drei Fällen bleibt die Datei lokal - nichts davon wird an einen Server gesendet. Der einzige Unterschied ist, ob das Werkzeug schon beim allerersten Offline-Versuch bereit ist. Ohne vorherigen Online-Besuch zeigen diese Fälle eine klare Fehlermeldung statt eines hängenden oder still fehlschlagenden Zustands; nach einem ersten Online-Besuch (oder bei wiederholter Nutzung) funktionieren auch sie offline.

Reichweite dieser Aussage, mit Datum

Stand der letzten vollständigen Prüfung: Jedes damals öffentlich verfügbare Werkzeug wurde einzeln gegen den oben beschriebenen Scanner UND die Content-Security-Policy gegengeprüft; keines wich ab. Das ist eine eigene, interne Messung - kein extern zertifiziertes Ergebnis -, und sie bezieht sich auf den Code-Stand zum genannten Datum. Ändert sich das, wird diese Seite aktualisiert, nicht die Aussage stillschweigend gehalten.

534 von 534 Werkzeugen bestätigt, 0 Ausnahmen (Stand 2026-07-25).

Stand dieser Seite

Empfänger-, Datenfluss- und Behauptungs-Register dieser Seite werden aus Quelldateien generiert; das Datum unten ist deren letzter tatsächlicher Änderungszeitpunkt in der Versionsgeschichte, nicht handgepflegt.

Zuletzt aktualisiert: 2026-07-25