> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blinkpdf.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Zero Retention — Blink PDF's Data Privacy Guarantee

> Blink PDF processes your Markdown input entirely in memory and never persists it. Generated PDFs, staged assets, and download links live at most 24 hours, then are purged.

When you send a document to Blink PDF, your **Markdown input** is processed entirely in memory and discarded the moment your PDF is returned — it is never written to a database, logged to disk, or retained beyond the lifecycle of a single API request. Rendered **outputs** — the PDF, any images you staged, and download links — are retained for at most **24 hours** to serve delivery and caching, then purged automatically.

## What zero-retention means

> *"Your Markdown input is processed in memory and never stored. Outputs live 24 hours at most. Nothing is ever used to train models."*

The input side is a hard architectural guarantee, not a configurable policy. The rendering pipeline is stateless with respect to your document content:

1. Your request arrives and is held in memory for the duration of the render.
2. The PDF is generated and streamed back to you.
3. The request payload — all Markdown content, 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, your submitted document is gone from memory.

<Note>
  "Purged immediately" applies to your **input**: Blink PDF does not use write-ahead logs, render queues, or persistent buffers that retain the Markdown you send after the response. Rendered **output** bytes and staged assets are a separate, time-boxed store described below.
</Note>

## What is NOT stored

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

* **Markdown content** — the document text you send in the request body
* **PDF metadata** — titles, authors, and custom fields you pass in the `metadata` field
* **Document structure** — headings, tables, and the intermediate parse tree
* **Remote images** — images fetched from `http(s)://` URLs during rendering are held in memory only and discarded after use, unless you opt into [`pinRemoteImages`](/configuration/document-options#the-pinremoteimages-field) (see the note below)

## What IS stored (for at most 24 hours)

To serve delivery, caching, and reusable assets, Blink PDF keeps a small, time-boxed set of data — all of it purged automatically after a flat **24-hour** window on every plan:

| Data type                                                | Retained                     | Purpose                       |
| -------------------------------------------------------- | ---------------------------- | ----------------------------- |
| Account email & credentials                              | Until you delete the account | Authentication                |
| API keys (hashed)                                        | Until revoked                | Request authorization         |
| Usage counters (render units, byte totals)               | Per billing period           | Billing and rate limiting     |
| Rendered PDF + download link                             | **≤ 24 h**                   | Delivery and render cache     |
| 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 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.

<Note>
  **Opt-in image pinning.** [`pinRemoteImages`](/configuration/document-options#the-pinremoteimages-field) 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, metadata, and document structure are still never persisted, and the [validate](/api-reference/overview) path never pins.
</Note>

<Note>
  **The MCP download flow.** Because an AI agent can't receive raw PDF bytes, the [Blink PDF MCP server](/mcp/overview) returns a signed download link (`GET /d/:token`) to the rendered output. That link and its stored object follow the same flat 24-hour window as every other output. Your **Markdown input is never persisted** in either the REST or MCP path.
</Note>

<Tip>
  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](mailto:sales@blinkpdf.io).
</Tip>

## Zero model training

Your data is never used to train, fine-tune, or evaluate any machine learning model — Blink PDF's own or any third party's. The rendering engine is deterministic software, not a learned model, and it has no feedback loop that ingests document content.

<Tip>
  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 [support@blinkpdf.io](mailto:support@blinkpdf.io) for the current status and timeline.
</Tip>

## 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 (discharge summaries, lab results) containing sensitive personal information can be generated without that input being written to disk or logged.
* **Finance** — trade confirmations, account statements, and KYC documents can be formatted as PDFs without exposing sensitive figures to a third-party data store.

<Info>
  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](/plans/enterprise) offers dedicated infrastructure and on-premise / VPC deployment.
</Info>

<CardGroup cols={2}>
  <Card title="Markdown Rendering" icon="file-lines" href="/concepts/markdown-rendering">
    See how the stateless in-memory rendering pipeline works end to end.
  </Card>

  <Card title="Accessibility" icon="universal-access" href="/concepts/accessibility">
    Learn about PDF/UA-1 compliance, Unicode support, and color emoji.
  </Card>
</CardGroup>
