How encrypted forms work

Almost every form is encrypted in transit and at rest, which still leaves the company running it able to read what arrives. An encrypted form closes that gap: the answers are sealed in the visitor's browser before they are sent, and what reaches our servers is ciphertext. A grievance report to an HR team, a safeguarding disclosure to a charity, case details going to a solicitor — those are the forms worth the extra step.

The mechanism is OpenPGP, the standard behind PGP and GnuPG. Your form carries a public key; you hold the matching private key. That trade is the entire feature, including the part nobody can undo: lose the private key and the responses stay sealed for good.

Encryption is configured per form, in the editor, and it has to be done before the first response arrives. Open the form, click the Settings tab, then the Encryption sub-tab — it sits between Notifications and Integrations.

The keypair is generated in your browser, not on our servers. The public half is saved to the form so visitors can encrypt to it. The private half downloads to your machine and is never sent to us. If you already use OpenPGP, switch to "Use existing public key" instead, paste your armoured public key block, and nothing new is generated.

Very little changes for them. Required fields, conditional logic and page breaks all behave as usual, because those run in the browser before anything is sealed. The difference arrives at the end: the submit button reads "Encrypting…" for a moment while the whole answer set is encrypted, then the response goes.

Under the form sits a small badge — "End-to-end encrypted with OpenPGP" — with the last sixteen characters of your key fingerprint beneath it, so anyone who cares can check it against the fingerprint you published. Uploads take the same route: file bytes are encrypted on the device, and the server never learns the filename or file type.

In the Submissions tab, rows on an encrypted form carry a padlock and a fragment of the armoured PGP message instead of answers. That fragment is genuinely all that is stored. Click a row to open the submission.

The submission page shows an "Unlock with your private key" panel. Paste the armoured private key block, or click Upload key file and pick the .asc file you saved. Enter the passphrase if the key has one, then click Decrypt. The answers appear laid out as they would be on any other form, and attached images decrypt into previews you can download under their real names.

The key is remembered in that browser so you need not paste it every visit. The passphrase is held in memory only. Keys already present are listed under "Private keys on this device", each with a Remove link, and every stored key is tried in turn — useful when you run several encrypted forms.

Once the first response lands, the key is frozen: an amber notice replaces the controls, because swapping keys then would strand the responses you already hold. To run the same questions under a different key, use Duplicate on the form's menu in the forms list and set the copy up from scratch. Before any response arrives you can still change course — "Use a different key" clears the current key behind a confirmation, and "Restore current key" puts it back if you clicked by mistake.

Everything downstream is sealed too, which is the point and also the cost. Email notifications say a response arrived but carry no contents. Search in the Submissions tab returns nothing, as there is no plaintext to match. Export CSV gives you submission times and the armoured payload, not columns of answers. Webhooks and the Zapier trigger send an encrypted flag and the same opaque blob, so a Zap can announce a submission but cannot branch on what it says.