One bad column becomes 200 wrong PDFs. Unless you see them first.

Mail merge for PDFs is the kind of task that seems finished until row 47, when you notice every single certificate has the recipient's name where the date should go. You mapped one column to the wrong field, the tool did exactly what you told it, and now you have a folder of 200 wrong documents and no idea until you open them one by one. The failure is invisible right up to the moment it's expensive.

Sheaf fills one fillable PDF form for every row of a CSV: permission slips for a class, offer letters for a batch of hires, W-9s for a dozen contractors. Drop a form and a spreadsheet, map columns to fields, get one filled PDF per row. The tools that already do this are either a desktop office suite you have to own and wrangle, or a web service that wants an account, a per-document fee, and, worst of all, your PDF and your spreadsheet of names and home addresses uploaded to its server first. For a task this small, handing your data to a stranger is a bad trade.

Nothing is uploaded, because there is no server

Sheaf does the whole merge in your tab. It reads the AcroForm field definitions straight out of your PDF with pdf-lib, parses the CSV client-side, auto-matches columns to fields by normalized name (so Full Name finds full_name, with a dropdown to fix any guess it gets wrong), and writes one filled, flattened PDF per row. It ships as a static site with no backend at all, which is what makes "no upload, no account, no fee" a fact about the architecture rather than a promise in the marketing. You can open the network tab and watch it stay silent while you work. The privacy claim only holds if it's true end to end, so there's no telemetry carrying document or CSV contents either.

Two libraries split the work because neither does the whole job well. pdf-lib reads and fills form fields but can't render a page to pixels. pdf.js renders beautifully but is clumsy at filling AcroForm fields. Using each for the one thing it's good at is much less painful than forcing either to do both. And filling plus rendering a few hundred PDFs on the main thread would freeze the tab solid, so the merge runs in a Web Worker with a progress bar and a cancel button that actually interrupts it mid-run.

The preview grid is the proof, not decoration

Here's the part that makes Sheaf feel different from a boring form tool. Before a single file downloads, you see a live grid of thumbnail previews of every filled document, rendered by pdf.js off the same worker. Change a column mapping and the whole grid updates instantly.

That grid isn't a flourish; it's the thing that catches the wrong-column disaster from the top of this post while it's still one glance instead of 200 opened files. A batch operation is normally invisible until it's done and wrong. Rendering every result up front turns the merge into something you can actually look at and sign off on. It's the difference between trusting the tool and verifying it, and verifying costs you about two seconds.

A related design choice: the messy inputs are treated as normal, not exceptional. A PDF with no form fields, a CSV with duplicate headers, a row missing a value, each gets a specific message you can recover from without reloading the page, rather than a stack trace or, worse, a silently wrong output. Those aren't edge cases for a tool like this. They're most of Tuesday.

Try it

Open Sheaf, drop any fillable PDF and a CSV with a header row onto the page, and watch it auto-match the columns to the form fields. Scan the preview grid, fix any mapping that looks off (the thumbnails redraw as you do), then download the whole batch as a ZIP named from whatever CSV column you pick, or grab one file at a time from its card. Once the page has loaded it works fully offline, and the code is on GitHub.