Zero Retention — Blink PDF's Data Privacy Guarantee

Blink PDF has two verbs: render (Markdown → PDF) and fill (a blank form + { name: value } → filled PDF). Your Markdown and your fill values are processed entirely in memory and discarded when the response closes — they are never written to a database, logged to disk, or retained beyond a single API request. Templates persist only if you store them. Rendered and filled outputs default to a 24-hour window. On the MCP server you can opt in to keep a PDF until you delete it; signed download links still expire in 24 hours.

What zero-retention means

“Your Markdown input and fill values are processed in memory and never stored. Templates persist only if you store them. Default outputs live 24 hours. MCP can keep a PDF until you delete it. Nothing from render or fill is ever used to train models.”

The input side is a hard architectural guarantee, not a configurable policy. Both pipelines are stateless with respect to the content you send:

Your request arrives and is held in memory for the duration of the render or fill.
The PDF is generated and streamed back to you (REST) or staged behind a signed download link (MCP).
The request payload — Markdown, fill values, metadata, and intermediate document state — is immediately purged from memory.

No background job, no async flush, no eventual-consistency delay retains your input. When the response closes, the Markdown or fill values you submitted are gone from memory.

“Purged immediately” applies to your input: Blink PDF does not use write-ahead logs, render queues, or persistent buffers that retain the Markdown or fill values you send after the response. Rendered and filled output bytes, stored blank templates, and staged assets are a separate store described below.

What happens to a filled medical form

This is the fill path for a medical form. You send a blank AcroForm (PDF bytes on the request, or a stored template id) plus a values map. A synthetic intake fill looks like this — field names and values are generic, not a clinic or client record:

{
  "templateId": "<id>",
  "values": {
    "patient_name": "Ada Example",
    "date_of_birth": "1970-01-01",
    "allergy_notes": "none recorded"
  }
}

What Blink PDF does with each piece:

Piece	What happens
Fill values (`patient_name`, `date_of_birth`, `allergy_notes`, …)	Held in memory for that request. Never stored. Not written to the template row, not logged, not kept after the response.
Blank template	Stored only if you store it (`POST /v1/templates` or MCP `store_template`). Sending PDF bytes on inspect, validate-fill, or fill does not upload a template.
Filled PDF	REST `POST /v1/fill` streams the bytes and does not keep them. MCP `fill_form` keeps the file 24 hours unless you set `persist: true` or later call `persist_pdf`.
Training	The fill values, the blank form, and the filled PDF are never used to train, fine-tune, or evaluate a model. The same sentence applies to render.

Inspect and validate-fill use the same input rules and do not write a PDF. Account erasure deletes stored templates and any persistent filled PDFs.

What is NOT stored

Your submitted document content is never written to a persistent store:

Markdown content — the document text you send on render
Fill values — the { name: value } map you send on fill (or validate-fill)
PDF metadata — titles, authors, and custom fields you pass in the metadata field
Document structure — headings, tables, and the intermediate parse tree
Live template bytes — an AcroForm you send as pdf on inspect, validate-fill, or fill, unless you separately store it
Remote images — images fetched from http(s):// URLs during rendering are held in memory only and discarded after use, unless you opt into pinRemoteImages (see the note below)

What IS stored

To serve delivery, caching, and reusable assets, Blink PDF keeps a small set of data. Most of it is time-boxed to 24 hours. Persistent MCP PDFs and stored blank templates are the exception and only exist when you ask for them.

Data type	Retained	Purpose
Account email & credentials	Until you delete the account	Authentication
API keys (hashed)	Until revoked	Request authorization
Usage counters (units, byte totals)	Per billing period	Billing and rate limiting
REST PDF response (`POST /v1/render` or `POST /v1/fill`)	Not stored by Blink PDF	Bytes stream back on the response
MCP PDF (default) + signed link	≤ 24 h	Agent download delivery for render and fill
MCP PDF (`persist: true` or `persist_pdf`)	Until `delete_pdf` or account erasure	Opt-in kept file (render or fill)
MCP signed link on a persistent PDF	≤ 24 h	Same `/d/:token` ceiling; `list_pdfs` mints a new one
Fill values	Never	—
Blank template (bytes on the request)	Never	Held in memory for inspect, validate-fill, or fill
Stored template (`POST /v1/templates` / `store_template`)	Until you delete it or erase the account	Opt-in blank library — not a filled output
Staged assets (`blink://asset/…`)	≤ 24 h	Reusable images you upload
Pinned remote image bytes (`pinRemoteImages: true` only)	≤ 24 h	Byte-identical repeat renders
Markdown content	Never	—

Usage counters record that a render or fill happened and how large it was — not what was in it. Your document content never touches the billing subsystem. Staged assets are scoped per credential and addressed by their content hash; the stored asset lives up to 24 hours. Persistent MCP files count against a per-plan object cap (Free 10 / Pro 100 / Business 1,000) — see Pricing. Stored templates have a separate object cap (Free 10 / Pro 50 / Business 250) and do not use those persistent-PDF slots. Templates belong to the account, not the API key: rotating a key does not orphan or leak the library.

Opt-in image pinning. pinRemoteImages is false by default — remote images are discarded after use. When you set it to true, only the referenced remote image bytes are retained, for up to 24 hours, scoped per credential and addressed by content hash. Your Markdown, fill values, metadata, and document structure are still never persisted, and the validate path never pins.

The MCP download flow. Because an AI agent can’t receive raw PDF bytes, the Blink PDF MCP server returns a signed download link (GET /d/:token) for render_pdf and fill_form. Default files follow the 24-hour window. persist: true or persist_pdf keeps the object; the link still expires in 24 hours. Your Markdown and fill values are never persisted on either the REST or MCP path.

Need a stricter posture — no output retention at all, or deployment inside your own environment? Enterprise plans run on dedicated infrastructure with data isolation, a zero-retention output option, and on-premise / VPC deployment. Contact sales.

Zero model training

Nothing from render or fill is ever used to train, fine-tune, or evaluate any machine learning model — Blink PDF’s own or any third party’s. That includes Markdown, fill values, blank templates, and the PDFs those verbs produce. Both engines are deterministic software, not learned models, and they have no feedback loop that ingests document content.

If you work in a regulated industry and need to document these guarantees for an audit, the retention policy is stated in the Blink PDF Terms of Service. A signed Data Processing Addendum (DPA) is on the roadmap — email [email protected] for the current status and timeline.

Why this matters for regulated industries

Industries with strict data-handling requirements — legal, medical, financial services, government — often cannot send document content to third-party services that log or store it, even temporarily. Zero-retention removes that blocker:

Legal — draft contracts, briefs, and privileged correspondence can be rendered without leaving your control boundary.
Medical — patient-facing documents and filled intake forms containing sensitive personal information can be generated without those inputs being written to disk or logged. See What happens to a filled medical form.
Finance — trade confirmations, account statements, and KYC documents can be formatted as PDFs without exposing sensitive figures to a third-party data store.

Formal certifications — SOC 2 Type II and a signed DPA — are on the Blink PDF roadmap, not yet available. If either is a hard requirement for your procurement process, contact the team for the current status and timeline. For workloads that need a stricter boundary today, Enterprise offers dedicated infrastructure and on-premise / VPC deployment.

Markdown Rendering

See how the stateless in-memory rendering pipeline works end to end.

Accessibility

Learn about PDF/UA-1 compliance, Unicode support, and color emoji.

Get Started

Fill a form

Core Concepts

Guides

MCP Server

Configuration

Plans & Limits

Help

Zero Retention — Blink PDF's Data Privacy Guarantee

What zero-retention means

What happens to a filled medical form

What is NOT stored

What IS stored

Zero model training

Why this matters for regulated industries

Markdown Rendering

Accessibility

​What zero-retention means

​What happens to a filled medical form

​What is NOT stored

​What IS stored

​Zero model training

​Why this matters for regulated industries

Markdown Rendering

Accessibility

What zero-retention means

What happens to a filled medical form

What is NOT stored

What IS stored

Zero model training

Why this matters for regulated industries