Check for yourself that nothing leaves

Three checks

1. The Network tab

   Open your browser's developer tools (F12), Network tab, then drop a message and turn it into a PDF. You will see the site's scripts and fonts loading, and no request carrying your message.

2. Airplane mode

   Load a tool page, turn off the network, then work. A service that uploads stops dead; here, everything keeps going.

3. The security policy

   View the page source: the Content-Security-Policy tag carries connect-src 'self'. The browser refuses any connection from the page to another domain, whatever code it runs.

The content security policy

It is the same on every page of the site, and it is what turns the promise into architecture: default-src 'self', connect-src 'self' blob: data:, img-src 'self' blob: data:, form-action 'none', object-src 'none', base-uri 'none'. No font is loaded from a provider, no script from a CDN, no analytics.

An email's body is shown in an isolated frame, without scripts, which inherits this policy: an image hosted elsewhere is refused there by the browser, which stops a message from telling its sender it was opened, and a form inside a message cannot send anything.

What does not leave

• The file and its content: read, displayed, laid out and saved in the tab.
• No DNS lookup: a message's DKIM signature is not recomputed, since that would mean asking a server for a key; the result shown is the one written by the receiving server.
• No timestamping: the production date written in a PDF is your computer's, and it is stated as such.
• No remote image, no third-party font or script.

The site's only request

After a save, your browser sends this domain a request with no body, containing only a family and a number: POST /compte?f=message&p=1. Nothing else: no file name, no content, no address, no cookie.

The family says what was opened: message for a dropped message file (.msg, .eml, .emlx, winmail.dat), boite for a message taken from a mailbox (.pst, .ost, mbox), discussion for a WhatsApp chat. The number is how many messages, or chats, the saved file covers: an attachment or one message's PDF counts 1, the attachments of twenty messages in one archive count 20. An exhibit file mixing message files and mailbox messages sends one request per family. The same message saved twice counts twice.

The counter's log records only a date, the family and that number, and only for a valid request. The site's access log records only a date, the response code and the requested page, without its query string. Neither keeps an IP address, a user agent or a referrer. The totals on the home page are drawn from them once an hour.

A browser that asks not to be tracked (Global Privacy Control, Do Not Track) sends nothing. A failed send is silent: it never prevents a save. Offline, nothing is sent, nor kept for later.

What your browser keeps to work offline

After you visit a tool page, a service worker keeps the site's code (the workshop, its readers, the PDF engine) and the pages of your language in the browser. You can then turn off the network and carry on, switching tools included.

The fonts and emojis used in PDFs (about 31 MB in all, 23 MB of them fonts) are kept only when first used, never in advance: a message in English needs 1.7 MB of them. The engine checks each file's fingerprint at every production, whether it came from the network or from this cache.

This cache holds only the site's own files: never one of your files, never the counter's request. It is cleared with the site's data, in the browser's settings, and renews itself with each version. Served without HTTPS or opened from a disk, the site works without it.

And the GDPR

Klarinbox processes none of the personal data in your messages: it never receives them. The publisher is therefore not a processor for what you open, and there is no transfer, no processing agreement and no retention period to set. You remain responsible for what you do with the messages, especially third parties' ones.