# Documents block

Hand files to the respondent — a contract draft, a price list, a how-to — as a download list inside the form.

## Documents block

Files usually travel one way — from the respondent to you. The Documents block sends them the other way: put the contract draft, the price list or the how-to right in the form, where the respondent reads it before answering.

<h2 id="what-it-is">What it is</h2>

<p>
  A Documents block is a titled download list. You upload one or more files once, give each a display name, and every respondent sees the
  same list — on a public link and on a <a href="/requests/overview">request</a> alike. Each row opens the file in a new tab and has a
  download button. The block asks nothing of the respondent: it collects no answer of its own.
</p>

<h2 id="add">Add one</h2>

Add document</strong> or drop files onto the block. PDF and images, up to 25 MB each, up to 20 documents and 100 MB in one block. They count against your workspace storage like any upload.',
    },
    {
      title: 'Name each row',
      description:
        'Click a display name to rename it — "Lease contract draft" reads better than "lease_v3_final.pdf". The file itself is untouched.',
    },
    {
      title: 'Publish',
      description:
        'Documents are part of the published form. A request created against that version keeps showing exactly those files, even if you replace them later.',
    },
  ]}
/>

<h2 id="acknowledgement">Ask for confirmation</h2>

<p>
  The block itself has no checkbox — you decide what "read" should mean. Add a required <strong>Switch</strong> question right below it,
  titled "I have read the lease contract", and the form cannot be submitted until it is on. Prefer several statements? Use a Checkbox with
  one option per document. Need a signature? Add a Signature question. All of them work with{' '}
  <a href="/building-forms/conditional-logic">conditional logic</a>, translations and exports as usual.
</p>

> 💡 **Why a separate question?**
> <p>
>     A Switch, a Checkbox and a Signature already do everything a built-in checkbox could, and they can be required, translated, referenced
>     in logic and read back through the API. The Documents block stays a list; the proof of reading is whatever question you put under it.
>   </p>

<h2 id="in-submissions">In submissions and exports</h2>

<p>
  Every completed submission records, under the block's <a href="/requests/field-keys">field key</a>, the documents that respondent was
  shown — its name and whether it came from the form or from a request. It appears in the submission view, in exports, in the PDF and in{' '}
  <a href="/requests/callbacks">callbacks</a>:
</p>

```
"documents": [
  { "name": "Price list 2026",     "source": "form" },
  { "name": "Your lease contract", "source": "request" }
],
"contract_read": true
```

<h2 id="per-request">Different files for each recipient</h2>

<p>
  On a <a href="/requests/overview">request</a>, an automation can add documents for that one recipient into the same block. They appear
  below your authored files, marked "For you"; the authored files stay exactly as published for everyone. See{' '}
  <a href="/requests/creating-requests#documents">Creating requests → Documents</a>.
</p>

<h2 id="limits">Limits</h2>

> ℹ️ **Office documents**
> <p>Word, Excel and PowerPoint files are not accepted yet — export them as PDF first.</p>

---

<div class="not-prose grid gap-4 sm:grid-cols-2">
  - [File uploads & signatures](/building-forms/file-uploads-signatures) — Collect files from respondents — the other direction
  - [Creating requests](/requests/creating-requests) — Add documents to a request from your automation
</div>