Security at gottrix

gottrix.app processes files 100% locally in your browser: the conversion code has no access to any foreign server (enforced by the Content-Security-Policy), so an upload is technically impossible. Delivery runs over TLS 1.2/1.3 with HSTS (2 years), a complete set of security headers, and hosting at Hetzner in Germany. Every claim on this page is verifiable yourself.

Zero-upload architecture: security by omission

Typical online converters upload your file to a server, process it there and send the result back - every one of those steps is attack surface. gottrix removes the critical step entirely: the engines (for images, PDFs, audio, video and more) run as WebAssembly directly in your browser. What is never transmitted cannot be intercepted in transit, cannot leak from any server, and cannot be demanded from anyone.

This is enforced by architecture, not by policy, with two strictly separated zones: the code that touches your file bytes (engines and web workers) is locked to its own origin by the Content-Security-Policy and contains zero network calls - an automated test verifies that on every build. The page level, which never sees your files, may only reach a documented analytics allowlist.

Engines and workers: 0 network primitives, no foreign origins - statically checked on every build.
Page level: foreign requests only to the documented analytics allowlist, never file bytes.
No upload fallback: if local processing fails, you get an honest error message - never a server detour.
Offline proof: after your first visit the tools keep working in airplane mode - the strongest evidence that nothing is sent.

Data flow: from your device to the server

Every request to gottrix.app first passes through the Cloudflare Edge network, which terminates the TLS connection and speeds up delivery, before being forwarded to the origin server at Hetzner in Germany. Cloudflare and Hetzner only process technical connection data such as IP address, requested URL and timestamp - never file contents, since those never leave your device. The optional feedback form adds two further branches (Cloudflare Turnstile for bot defense, Resend for a single internal notification); the anonymous usage analytics runs, only with your consent, directly from your browser to Google Analytics 4. The full recipient table with all data categories and legal bases is further down this page.

Recipients of your (connection) data

The table below lists every external recipient that processes technical data while operating gottrix.app - generated from the same register as the privacy policy, so the two pages can never drift apart. Your file contents appear in no row, because they never reach any of these recipients.

Recipients of your (connection) data
Recipient	Role	Seat	Data categories	Legal basis	Transfer mechanism	Retention
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 days
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)	not concretely determinable
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	not concretely determinable
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	usually 180 days

Retention periods at a glance

Every retention period known on gottrix.app, in one place, concrete rather than vague:

Retention periods at a glance
Server access logs (Hetzner, origin)	90 days
Feedback submissions (database)	usually 180 days
Google Analytics 4 (usage analytics)	not concretely determinable

Google Analytics 4’s retention is configured in the Google Analytics property, not in gottrix.app’s source code - the concrete value cannot be verified from here. All legal bases are in the privacy policy.

Transport: TLS and HSTS

The website is delivered exclusively over HTTPS - TLS 1.2 and 1.3 with modern cipher suites and automatically managed certificates. HTTP Strict Transport Security (HSTS) is set with max-age=63072000 (2 years) including subdomains: the browser then enforces HTTPS by itself on every future visit. For perspective: your file contents never travel over this connection, because they never leave your device - transport encryption protects the delivery of the site itself.

HTTP security headers

Every server response carries a complete set of security headers. The values are configuration, not aspiration: an automated test aborts any deploy where one is missing or differs.

HTTP security headers
Header and value	Effect
Strict-Transport-Security: max-age=63072000; includeSubDomains	Enforces HTTPS for 2 years, including all subdomains.
X-Frame-Options: DENY	No embedding of the site in foreign frames (clickjacking protection, doubly secured via frame-ancestors in the CSP).
X-Content-Type-Options: nosniff	Stops the browser from guessing content types and executing files as script.
Referrer-Policy: strict-origin-when-cross-origin	Passes at most the origin to foreign sites, never full URLs.
Permissions-Policy: geolocation=(), usb=(), camera=(self), microphone=(self), ...	Disables 12 device and sensor APIs (location, USB, the privacy-sandbox APIs Attribution-Reporting/Browsing-Topics/Interest-Cohort and more) the site does not need; only fullscreen, screen sharing, camera and microphone (for the respective recording tools) stay allowed for the own origin.
Cross-Origin-Opener-Policy: same-origin	Isolates the browsing window from foreign pages that opened it.
Cross-Origin-Resource-Policy: same-origin	Stops foreign sites from embedding or reading resources from this origin.

The Content-Security-Policy in full

The CSP is the technical lock behind the zero-upload guarantee. It is generated from a single source file and rendered here live from exactly that source - all 17 directives, unabridged:

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 (checked on 2026-07-09): 0 findings of severity High. Besides the own origin, connect-src permits only the documented page-level analytics allowlist - metadata, never file contents.

The existing Content Security Policy (default-src 'self') also acts as a technical advertising lock: it does not allow the delivered code to connect to any foreign origin at all. Even an accidentally injected advertising or tracking script could not function as a result - the browser blocks any such connection based on the policy. This is not an announcement, but a property of the existing architecture that is verifiable in the source code.

A deliberate choice: Privacy Sandbox APIs stay blocked

The Permissions-Policy row above fully blocks browsing-topics=(), attribution-reporting=() and interest-cohort=() - that is not incidental configuration, it is a deliberate, permanent decision. These three APIs are part of Google's "Privacy Sandbox": replacement mechanisms for the classic tracking cookie that would let the browser itself build interest profiles or store ad-attribution data. Blocking them is not a technical footnote for gottrix, it is a differentiation feature, consistent with the null-upload architecture: where file contents never leave the browser in the first place, an in-browser interest profile has no place either.

Advertising networks

As of 2026-07-25: gottrix does not currently integrate any advertising networks. Should this change, it will be disclosed here and in the privacy policy before the change takes effect.

Independent verification

Three external reviews are firmly planned and will run against the live domain at public launch: SSL Labs (TLS configuration), Mozilla Observatory (HTTP security posture) and securityheaders.com (header completeness). Results are shown and linked only once the scans have actually run - gottrix never displays unverified seals or grades, and an automated test in every build enforces exactly that.

No upload100% local

Your content stays with youno third-party access

Hosted in GermanyGlobal Content Delivery

Independently auditedTLS A+ · HTTP headers A+

Hosting and data location

The origin servers are operated by Hetzner Online GmbH in Germany and are subject to the GDPR. They hold nothing but the static website: no user accounts, no file contents, no content database. Server logs contain only technically necessary access data with a 90-day retention period; a data processing agreement with Hetzner is in place. Since file processing happens locally in your browser, your file contents never reach this location anyway.

Analytics and consent

The anonymous usage analytics (Google Analytics 4 with Consent Mode v2 Advanced) starts with all signals set to denied: without your consent, no analytics cookie is set and no identifier is created. With consent, at most page views and the id of the tool used are measured - never file names, file sizes or file contents. All details and legal bases are in the privacy policy.

Read the privacy policy

Notice for businesses and authorities

gottrix ends a privacy or security review instead of opening one: because file contents never leave the browser, no transmission to us occurs for them technically - and without transmission, there is no processing that a review would even need to stop. That holds regardless of who opens the file: a law firm, a medical practice, a tax office, an HR department, a public authority, or a private individual.

For file contents, no data processing agreement arises, because no transmission takes place - there is no processing operation at gottrix that a contract would need to govern. For delivering the website, the consent-based usage analytics, and the separate feedback form, the operator is the controller, not a processor. It follows that a data processing agreement (DPA) under Art. 28 GDPR is neither required nor legally fitting for using the tools themselves - so we deliberately do not offer a DPA template for file processing.

This assessment applies explicitly only to file contents. For website delivery via Cloudflare and the usage analytics (Google Analytics 4), gottrix itself is the controller under data protection law, and data processing agreements with the respective providers are in place for those services (see the privacy policy). Anyone who needs a DPA for the website layer will find the contracting parties there - just not for file contents, because there is no processing operation a DPA would need to cover.

By profession and industry

Lawyers and law firms

Client files are protected by attorney-client confidentiality obligations and, in Germany, criminally protected under Section 203(1) no. 3 of the Criminal Code (StGB). In our assessment - not legal advice for your specific case - using gottrix changes nothing about that structurally: a file that never reaches a foreign server is also never disclosed to anyone.

Do I breach my duty of confidentiality by processing a client file with gottrix?

In our assessment, no, because no disclosure occurs: the file stays technically on your device, gottrix never sees it. A binding answer for your specific case can only come from your bar association or dedicated legal counsel.

Do I need a data processing agreement with gottrix?

Not for file contents - no processing takes place that a DPA would need to govern (see the role model above). That does not apply to website analytics - see the layer-separation paragraph.

Doctors and medical practices

Patient records fall under medical confidentiality and, in Germany, under Section 203(1) no. 1 StGB, and regularly count as health data under Art. 9 GDPR. In our assessment, the same structural reasoning applies as for lawyers: without transmission, there is no disclosure to gottrix.

May I convert a medical letter or a lab result with gottrix?

In our assessment, yes, because the file never leaves your device - no third party gains access to its content. For especially sensitive workflows, an additional internal IT or privacy sign-off from your practice or clinic is still advisable.

Tax advisors and auditors

Tax advisors, certified public accountants and auditors fall under the very same confidentiality-protection provision as lawyers and doctors (in Germany, Section 203(1) no. 3 StGB), on top of their own professional confidentiality duties. Client files and annual-accounts documents converted with gottrix never leave the device in the process.

Can I process a client's receipts or annual-accounts PDFs with gottrix?

In our assessment, yes, for the same structural reason as with lawyers: no transmission, no disclosure. The final assessment for your firm rests with your professional body or your internal compliance team.

HR and personnel departments

Payslips, employment contracts and job applications are personal data, some of it especially sensitive under the GDPR - no new special rule is needed to reach the same result: because the file never travels to any server outside the device, using gottrix itself creates no additional processing under Art. 4(2) GDPR.

May we convert payslips or employment contracts with gottrix?

In our assessment, yes - no additional processing step arises because the file stays local. An internal sign-off from your privacy team remains sensible, but does not replace your own case-by-case review.

Public authorities and the public sector

Alongside the GDPR, public authorities are often bound by their own duty of official confidentiality, which varies by state, agency and remit - we deliberately do not name one single provision here, since it differs by jurisdiction. The structural point stays the same: a file gottrix never receives also cannot be improperly disclosed by us.

Can we use gottrix for official documents if cloud services are not permitted for us?

Often yes, because the conversion involves no upload - exactly the criterion a cloud ban typically targets. The binding sign-off rests with your own IT security or data protection office, based on your own rules.

Businesses in general (B2B)

Contracts, internal calculations, M&A documents or personnel data - for any kind of trade secret or confidential document, the same structural advantage applies: there is no upload step where a third party could read along.

Is gottrix suitable for trade secrets and confidential contracts?

In our assessment, yes, because the file never leaves the device - a confidentiality breach through transmission is structurally excluded, not just contractually promised. An internal sign-off under your own IT policy remains sensible regardless.

Private individuals

A payslip, a lease, a lab result, a bank statement: even without a professional confidentiality duty, a private file is nobody's business but your own. Because gottrix never sees it, none of us can accidentally forward it, lose it, or use it for anything else.

Is it safe to process my payslip or ID document with an online tool?

With gottrix, yes, because no upload happens: the file stays in your own device's memory. Even so, the general rule still applies: only share the result afterwards with whoever actually needs it.

What gottrix does not have

No ISO 27001 certification.
No SOC 2 (Type I or II).
No single sign-on (SSO) or identity federation for enterprise accounts.
No contractual support service-level agreement (SLA).

These gaps are named deliberately, not hidden: a review that ends at an admitted gap is more honest than one that fails at a discovered one.

Contact for data protection officers: info@gottrix.app

Responsible Disclosure

Found a vulnerability? We welcome responsible reports. Please test only against your own device/browser, without causing data loss, service disruption, or accessing other users’ data - given gottrix’s null-upload architecture, that in practice means CSP bypasses, XSS, header or TLS misconfigurations, and similar web vulnerabilities of the delivered site itself.

Good-faith testing under this policy will not lead to legal action from gottrix. We acknowledge receipt, prioritize by severity, and keep you updated on progress - currently a solo project with no fixed response-time SLA, but genuine interest in every report.

Security contact: info@gottrix.app

Common questions about security

Is gottrix.app secure?

Its security rests on architecture rather than promises: files are processed exclusively locally in your browser and never transmitted to any server - a strict Content-Security-Policy forbids the conversion code every foreign connection. On top of that come TLS 1.2/1.3 with HSTS, a complete set of security headers and hosting in Germany. Each of these points is verifiable yourself in the source, the network tab or via the airplane-mode test.

Are my files uploaded or stored anywhere?

No. Conversion runs entirely in your browser’s memory; there is no upload endpoint and no server-side storage for file contents. The Content-Security-Policy denies the engine and worker code any connection to foreign servers, and an automated test verifies that on every build. Close the tab and the data is gone - there is nothing that would need deleting server-side.

What encryption does gottrix.app use?

The website is delivered exclusively over HTTPS with TLS 1.2 and 1.3 and modern cipher suites; HSTS enforces HTTPS for two years including subdomains. Your file contents themselves never travel over any connection, because they never leave your device - transport encryption protects the delivery of the site and the optional, consent-based usage metadata.

Where are the servers hosted?

The origin servers are operated by Hetzner Online GmbH in Germany, under the GDPR. They hold nothing but the static website: no user accounts, no file contents, no content database. Because processing happens locally in your browser, the server location is irrelevant for your file contents - they never reach it at any point.

How can I verify these security claims myself?

Three ways that need no special expertise: the airplane-mode test (open a tool, disconnect, convert - it keeps working), the network tab of the developer tools (F12: no file request during conversion), and the response headers any browser can display. The step-by-step guide is on the proof page; at public launch, external scans by SSL Labs, Mozilla Observatory and securityheaders.com are added.

What data does gottrix collect at all?

Without your consent: no analytics cookies and no identifiers, only technically necessary server logs with a 90-day retention period. With consent, Google Analytics 4 measures aggregated usage such as page views and the id of the tool used; file names, file sizes and file contents are never recorded. The full legal bases and how to withdraw consent are in the privacy policy.

Verifiability: how to check this yourself

Every claim on this page can be checked yourself with tools already on your machine - from the airplane-mode test to the network tab of the developer tools. The full step-by-step guide lives on the proof page. The check script behind this guarantee is itself open in this project’s source code under oss/gate-null-upload-static/ - open to inspect and reuse.

How this is verifiable

The technical proof: how NULL-UPLOAD is implemented

This section is written for developers, security teams, and anyone who wants to verify rather than trust. It describes how the local-processing model is actually implemented in the code - with concrete examples, the enforcement mechanism, and the honest limits of where things stand today. None of this is a promise; all of it is checkable.

Two zones, one boundary

The code is split into two zones - not only in documentation, the split is enforced at build time. The first zone (the conversion engines, the Web Worker pipeline, the run layer, and the calculators' computation cores) holds the file bytes: it reads them, transforms them, hands them back. This zone is architecturally forbidden from containing any network primitive at all - no fetch, no XMLHttpRequest, no sendBeacon, no WebSocket, no foreign address as a string literal.

The second zone is the page itself (layout, usage measurement). It is allowed to use the network - but strictly for usage metadata (page views, which tool was used) sent to a fixed allowlist, never for file contents. The split is drawn deliberately narrow: the code allowed to talk to an analytics or advertising network is a different codebase from the one that ever sees your file.

A concrete example from the first zone: when a file is dropped, the browser reads it through the file-system interface into an ArrayBuffer in the page's own memory. That byte array is handed to a Web Worker via postMessage - a second thread of execution in the same browser, started as its own module worker: new Worker(new URL('../workers/pipeline.worker.ts', import.meta.url), { type: 'module' }). The actual conversion code runs there.

Two engines, in detail

Plain JavaScript: merging PDFs

PDF merging runs on the pdf-lib library - plain JavaScript, no WebAssembly component. Pages are copied object by object from the source files into a new document, not re-rendered. The result comes back from the worker as bytes, becomes a Blob, and from there a download link. The entire path is memory, then worker, then memory again, then disk - a network connection is never part of it.

WebAssembly: AVIF and JXL image codecs

Other engines need genuine WebAssembly, because the browser cannot decode or encode those formats natively - for example AVIF and JXL encoding via the jSquash codecs. The WASM binaries are bundled at build time as a standalone, same-origin file import: the bundler copies them alongside the rest of the code, and the engine loads them from there, never from a foreign address. Whether an engine uses JavaScript, WebAssembly, or a conditional mix of both is documented in the code itself, not merely asserted.

The hard enforcement: a source scanner, not a promise

The split would be worthless if it stayed a mere convention. So before every release, a static scanner runs over exactly the program parts where file bytes live. It fails the build the moment any of the following appears:

fetch(), XMLHttpRequest, navigator.sendBeacon, new WebSocket, EventSource, importScripts()
a foreign address as a string literal (any http(s):// substring, aside from a handful of narrowly justified, never-fetched exceptions such as XML namespace constants)
a beacon-shaped assignment such as img.src = "https://..."
any reference to a tracking script (gtag(), googletagmanager, google-analytics) - those are only allowed in the page layer, never where file bytes are processed

Beyond the obvious conversion engines, the scanner also covers the calculators' computation cores, the interaction modules, and every helper library imported into those zones - not only the files that look like an engine. A second, independent check reads the shipped Content-Security-Policy: it allows network connections only to the site's own origin plus a short, explicitly named analytics allowlist - any other address would be a policy violation the browser itself blocks, regardless of the source code.

The Content-Security-Policy as a second, browser-enforced barrier

Even if the source scanner missed a new network call, a second barrier applies, enforced by the browser itself: the shipped connect-src directive allows only the site's own origin plus three explicitly named analytics addresses. Any other destination is blocked by the browser before the request ever leaves the device - regardless of what the code attempts:

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

Verify it yourself, without trusting us

Open developer tools (F12), Network tab. Start a conversion and watch the list: no request appears that could contain your file at all - only page assets that were already loaded before the conversion.
Disconnect the internet (airplane mode) and run the conversion again. For the large majority of tools it keeps working unchanged - the strongest evidence, because a provider that computes on a server can never pass this test.
Inspect the shipped security policy directly: in the Content-Security-Policy response header of any request to the site, or via a public CSP analysis tool. The connect-src line is the short text quoted above - nothing more.
Check the Application, then Service Worker tab: after the first load it shows an active worker with its own cache - that is the mechanism that makes offline use possible at all (more on that below).

The offline test - and its honest limits

After the first page load, a service worker pre-loads the program parts a given tool needs in the background, while the connection still exists. If the connection is then cut, the large majority of tools keep working unchanged - including a complete conversion. That is not a side effect, it is the direct proof: a service that processes your file on a server cannot pass this test.

What does NOT yet work on the very first offline attempt

Ten conversion engines with unusually large program parts (among them HEIC conversion, AVIF/JXL encoding, and several PDF analysis tools) sit above the size ceiling up to which parts are pre-loaded - together they cover more than ten individual tool pages. Pre-loading them for everyone would be needless data use for the large majority of visitors who never convert.
The visual PDF editors load their preview through a larger rendering module that is likewise not pre-cached.
Roughly 47 tools fetch a large add-on module (video/audio encoding, speech recognition, text recognition) only at the moment of first use, not ahead of time - that is not sensibly compatible with any pre-loading strategy.
In all three cases the file stays local - none of it is ever sent to a server. The only difference is whether the tool is ready on the very first offline attempt. Without a prior online visit, these cases show a clear error message instead of a hanging or silently failing state; after a first online visit (or on repeat use), they too work offline.

The scope of this statement, dated

As of the last full check: every tool publicly available at the time was checked individually against both the scanner described above and the Content-Security-Policy; none deviated. This is our own internal measurement, not an externally certified result, and it refers to the code as of the date given. If that changes, this page is updated rather than the statement being quietly kept.

534 of 534 tools confirmed, 0 exceptions (as of 2026-07-25).

Status of this page

This page’s recipient, data-flow and claims registers are generated from source files; the date below is their most recent actual change in version history, not hand-maintained.

Last updated: 2026-07-25