Trust

Most PDF APIs say they don’t keep your documents. We say it on every response, sign it, and remove the options that would let anyone turn storage back on.

Headers on every render

Response headers

pagenull-retention: none
pagenull-region: <provider-city>
pagenull-render-id: 6f1c2a9e-0b7d-4a51-9c3e-2d8f4b7a1e60
pagenull-renderer: <renderer image digest>
pagenull-receipt: v1.eyJ2IjoxLCJraWQiOi….3m1Q…
pagenull-pages: 2

`pagenull-retention`	Always `none`. Nothing from the request or its output was written anywhere.
`pagenull-region`	Where the render ran, as set by the operator. Current value: not set yet (hosting provider TBD).
`pagenull-render-id`	The only identifier we log, with your account id, status, duration, size and page count. Quote it to support.
`pagenull-renderer`	The digest of the renderer image that produced the file.
`pagenull-warnings`	Problems spotted during the render, like missing glyphs or overflowing content. How we help you debug without keeping your data.

Signed receipts

pagenull-receipt is an Ed25519 signature over the render id, the SHA-256 of the output, the time, the region, the renderer digest and stored: false. Check one on the verify page, with pnpm verify-receipt, or with any Ed25519 library and our key at /.well-known/pagenull-keys.json.

Be clear about what that means. A receipt proves what we produced, when, where and with which image. It cannot prove that we deleted anything, because nothing can prove a negative from outside. That part rests on the next section, on the open renderer, and on the DPA.

There is no storage option

No parameter makes pagenull keep a document: no file links, no “log this request”, no debug retention.
If you need the file somewhere else, pass deliverTo with a presigned URL in your storage. We upload it and keep nothing.
Our logs accept only metadata fields. An automated test fails the build if any code path writes request content or output to disk, or logs outside that logger.
Saved templates are the one thing you can ask us to keep. They’re encrypted at rest and you can delete them any time.

Sub-processors

Draft, pending legal review. Payments go through Creem. Providers marked TBD have not been confirmed yet; we won’t name one here until a contract exists. Changes are announced here 30 days in advance.

Role	Company	What it receives	Document content	Location
Hosting	TBD (not chosen yet; must be an EU company with EU data centres)	Account data, encrypted templates, request metadata. Documents pass through server memory during a render.	In memory only, during a render	EU (TBD)
Payments (merchant of record)	Creem	From us: your account email and an internal user id. At checkout you give Creem your name, billing address, payment details and VAT ID.	Never	Estonia (EU)
Transactional email	TBD (EU provider)	Email address and the emails we send you	Never	EU (TBD)
Ad measurement (only if you accept ad cookies)	Meta Platforms Ireland Ltd	Pixel events from marketing pages; hashed email at sign-up	Never	Ireland / USA

No error-tracking or analytics service receives request data. To be told about changes, email privacy@pagenull.dev.

The renderer

Rendering runs in its own container: headless Chromium behind a small authenticated API, with a read-only root filesystem, memory-only scratch space, no volumes and no database access. Chromium has no direct network route; every request a page makes goes through one guarded fetcher that refuses private, loopback, link-local and metadata addresses, including after redirects and DNS resolution. The source is in packages/renderer; publishing it and the production image digest is on the roadmap. Until then this paragraph is a description, not something you can check.