Encryption and privacy

EveryPage encrypts your documents at rest and discards visitor IP addresses, replacing them with pseudonymous reader identities. This is encryption at rest, not end-to-end encryption: EveryPage holds the keys. This page explains what that protects against and what it does not.

Document encryption at rest

Your documents are encrypted with AES-256-GCM before being written to disk. Which key is used depends on how the file arrived:

• Files uploaded to an account are encrypted with that account's own encryption key, generated when the account is created and versioned thereafter. The key itself is wrapped (encrypted) with a master encryption key and stored in the database — the plaintext key is never at rest.
• Anonymous uploads get a random key generated for that one file, wrapped with the same master key and stored on the file's database row. Claiming an anonymous upload into an account does not re-encrypt it: it keeps the key it was uploaded with, which is why the shared link keeps working.

The upload never holds the whole document in memory. As bytes arrive from your browser they are streamed into a chunked encryption format — a 16-byte header followed by chunks of up to 1 MiB of plaintext each, sealed individually. Chunk nonces are constructed, not random: a random per-file prefix, then a chunk counter, then a final-chunk flag. The counter makes reordered chunks fail authentication and the flag makes truncation detectable, so a stream cut short by accident or attack does not decrypt as a valid shorter document. The header is used as additional authenticated data for every chunk, binding each one to this file's parameters.

When a viewer opens or downloads your document, EveryPage reads and decrypts it on demand using the same streaming format. If the file carries a watermark or a page range, the decrypted document is written to a temporary file so it can be rewritten through pdfcpu before streaming; that temporary file is deleted when the request ends. Files with neither transform are streamed straight through without ever being fully materialized.

Important limitation: this is encryption at rest, not end-to-end encryption. EveryPage holds the keys and can read your documents. The protection this provides is against someone who obtains the stored files without the master key — a stolen disk, a backup, a compromised storage provider. It provides nothing against an attacker who obtains the EveryPage server or the master encryption key, and nothing against EveryPage as the operator. If your threat model includes the platform itself, you need end-to-end encryption, where only you hold the key, and EveryPage does not offer it.

Visitor identification without IP storage

When someone views your document, EveryPage does not store their IP address. Instead, the address is run through a salted HMAC-SHA256 and only that hash is kept, as the key to a stable pseudonymous reader identity. Historical rows that predated this were converted to reader identities and their stored addresses scrubbed.

The salt is configured per deployment and can be changed. Changing it changes the hash of every address, which re-buckets every reader under a new pseudonymous identity — existing readership history stays attached to the old identities. You cannot look up a reader's IP address from your readership data, because the address was never stored, and the mapping is not reversible. If you need to block a specific address, that is not something your readership data can tell you.

The address is still processed in flight while the request is being handled. Rate limiting and abuse caps operate on it, and country lookup sends it to an external geoip service (ip-api.com) over plain HTTP. The address is discarded afterwards, but it does leave the server for that lookup.

The country that lookup returns is stored, on the same view-session and access rows that carry the pseudonymous reader identity — that is what makes the country breakdowns in your readership reports possible. So a country is associated with a reader identity; what is not stored is the address it was derived from.

This approach gives you stable returning-reader detection and per-page timing without holding visitor addresses. It costs you the ability to look up or block a specific address later.

Lead-capture data and consent

If you enable an email gate on your document, every viewer who submits the gate provides contact information that you chose to collect. That captured email address and any additional form fields (name, company, phone) are personal data you control, and they are stored in your readership data and events feed. Lead data is Pro-tier for viewing; you cannot see captured leads if you downgrade.

See Email gates and lead capture for details on how to set up, manage, and export captured data.

Link-variant labels

If you create link variants (personalized links sent to specific recipients), each variant carries a recipient label as its only personal field. That label can be redacted on request, which NULLs it from stored analytics and webhook payloads containing that variant's data.

See Link variants for details on creation, attribution, and redaction.

Key versioning and the rotation limitation

Per-account encryption keys are versioned. Each file records the key version it was encrypted under, and that version is unwrapped when the file is served.

There is no self-service key rotation: rotating an account's key is not exposed in the app or the API on any plan. The underlying operation exists on the platform side, and it carries a limitation worth stating plainly — rotating a key creates a new version but does not re-encrypt existing documents. Files keep the version they were written with, so every old key version must remain unwrappable for as long as any file still uses it. Old wrapped keys are therefore retained in the database rather than deleted.

The consequence: if a key version were compromised, existing files encrypted under it could not be retroactively protected by rotating. Only files uploaded after the rotation would use the new version. Documents do not all age out on their own, either — Pro documents can be set never to expire, and anonymous uploads are retained for a year.

Transparency and limits

For a full picture of what EveryPage measures about your readership, see What EveryPage measures.

For technical details on how reader identities work and how they flow through your readership reports, see Reader identities.

For integration-specific measurement, see Google Analytics.