Decrypting a PGP file without uploading it: how it actually works

Because this tool handles files people have deliberately encrypted, the usual "trust us" is not good enough here - so the mechanism and how to verify it are spelled out in full below.

What actually happens when you decrypt inside the browser

Decryption runs through openpgp.js, a complete, open-source implementation of the OpenPGP standard (RFC 9580/4880). Its own source comment states plainly that the library is pure JavaScript - no WebAssembly component, no network calls, no eval - and that the browser build relies only on the browser's native Web Crypto API plus BigInt for the underlying large-number math.

Your private key, its passphrase, and the encrypted message are handed to a dedicated Web Worker, a second thread inside the same browser tab, the same one every file-processing tool on this site uses. Inside that Worker, three library calls do the actual work in sequence - reading the private key, unlocking it with your passphrase, then decrypting the message - and the recovered original file is handed back to the page as bytes.

That Worker area of the code is checked automatically, on every single change, to contain zero network primitives at all: no fetch, no XMLHttpRequest, no sendBeacon, no WebSocket. It is not a promise resting on good intentions; it is a build-time check that would fail the moment anyone tried to add one.

If the passphrase is wrong, or the message was encrypted to a different key, the library fails with a clear, honest error rather than guessing - it will never hand you a garbled or partially decrypted file and call it done.

How to check this yourself, in a couple of minutes

1. Open your browser's developer tools (F12) and switch to the "Network" panel. Leave it open for everything that follows.
2. Disconnect completely - airplane mode, or Wi-Fi off - before you have used the tool even once.
3. Paste your private key and passphrase, drop the encrypted file, and let it decrypt. It completes on this very first attempt, and no entry in the Network panel ever carries your key, your passphrase, or the file - only the page's own generic assets, which were already there before you dropped anything.

Works offline This tool works offline on a genuinely first-ever attempt - you do not need to have decrypted anything while online beforehand. Once the page has loaded, your browser fetches everything it needs in the background; after that, decryption works without a connection too, even if you try it immediately - verified byte-for-byte identical in an automated test.

What this means under GDPR Article 28

Legal background (not legal advice, just context): under GDPR Article 28, a data processing agreement (DPA) is required whenever personal data is handed to a third party for processing - for example when a file is uploaded to a server so that server can convert, read or store it. With gottrix that handover simply does not happen: the file is decrypted inside a dedicated Web Worker with zero network access, so gottrix never sees the file contents and therefore cannot store, analyse or forward them either. This does not change other obligations that do apply (for the few server requests that genuinely happen - the page load itself, consent-gated analytics); our own privacy policy (/en/datenschutz) covers those. Other providers in this space commonly process files server-side (the file is uploaded, processed there, and deleted after a defined retention period) - that is a technically different, in many cases equally lawful model, but one that requires handing data to a third party and therefore a DPA. This context is not a substitute for individual legal advice.

For this tool specifically, the same reasoning applies to your private key and passphrase, not only to the file: they are security material, not just content, and they too are processed exclusively inside your browser and never transmitted anywhere. No question of a data-processing agreement arises for them either, for the same reason it does not arise for the file itself.

Read the full privacy policy for both layers

The difference to a server-based PGP tool

A common alternative design looks different but is not disreputable on its own: the encrypted file - and in some designs the private key and passphrase as well - is sent to a server, decrypted there, the result returned, and the inputs deleted after a defined period. Choosing that path means trusting that the period and the access controls really are honoured.

For an already-encrypted file, that dependency is a bigger step than for an ordinary document: the entire reason someone encrypts a file with PGP in the first place is to avoid handing it, or the key that opens it, to anyone but the intended recipient. A server-based decryption step re-introduces exactly the kind of third party that PGP itself is designed to keep out.