Mail merge without uploading your data
Short version
- Most tools upload the sheet because generating on a server is the easy way to build one.
- Whether that matters depends on whose data is in the rows: your own, or three hundred other people's.
- You can check any tool yourself. Open the browser's network tab, run a merge, and watch whether the file leaves.
Why they ask for the file
Not because anybody wants your spreadsheet. Because rendering a PDF on a server is the straightforward way to build this kind of product: one rendering engine you control, one set of fonts, no browser to disagree with you, and a queue you can watch. Doing the same work in the visitor's browser is more awkward to build and harder to debug, so most products do not.
The consequence is the same wherever it comes from. To make three hundred documents, the service has to hold the three hundred rows — names, addresses, amounts, sometimes tax numbers — for as long as the job takes, plus whatever the retention period says.
That phrase is worth learning to spot. A retention period is a promise to delete later, which is also a statement that they have it now. Every tool that offers you a configurable one is telling you, accurately, that your files sit on their disk until it expires.
When it does not matter
Often. If the rows are your own — your products, your prices, a list you invented for a test — then uploading them costs you nothing you care about, and server tools do things a browser cannot. They send the email themselves. They expose an API you can call from a script. They run a hundred thousand rows without your laptop's fan coming on.
If that is your situation, the honest advice is to pick on features and price and stop reading here.
When it does
The rows are usually not yours. A contract run holds your clients; a payroll letter holds your staff; a school's certificates hold children's names. You did not collect that data to hand it to a tool you found in a search result, and you are the one who answers for it if it goes somewhere unexpected.
There is also a plain arithmetic to it. A batch is one template and three hundred rows: the template is the part you wrote, the rows are the part that belongs to other people, and the rows are almost all of the volume. Keeping the small part somewhere and the large part nowhere is not a compromise, it is the shape of the problem.
How to check any tool in ten seconds
- Open the developer tools in your browser and go to the Network tab.
- Load your spreadsheet into the tool.
- Look for a request carrying the file — a
POSTwith a body the size of your sheet. If the file leaves, it is right there, and no wording on the marketing page changes it. - Then generate, and look again for the documents coming back down.
This works on us too, and it is the only reason to believe any of this. Nothing on this page is worth as much as the empty network tab.
What still reaches our server, because something does
“No data leaves your computer” would be a lie, so here is the whole of it.
- Your spreadsheet: never. It is read in the browser. The rows, the values, and every finished PDF stay on your machine.
- Your email address, if you make an account, so we can write to you, and so the subscription belongs to somebody.
- The text of a template, if you choose to save one. Saved templates live in a database of ours, encrypted, because the point of paying is that they are still there in six months and on your other computer. A template is the part you wrote; it holds no client of yours.
Nothing else. If you never make an account, the second and third do not happen either — you can use the whole of the free tier without telling us who you are. What we hold and where is written out on the privacy page.
Questions
Is this encryption, or is it just not sending it? It is not sending it, which is the stronger of the two. Encrypted-in-transit means somebody decrypts it at the other end.
Does it work offline? Once the page has loaded, the merge itself needs no network. That is a consequence of where the work happens rather than a feature we built.
Is it slower, running in a browser? No. Three hundred PDFs take a couple of seconds, and on a phone about twenty-six. There is no queue in front of you because there is no queue.
What about very large batches? Reading the sheet happens on the main thread, so a very large file freezes the page while it loads. That is the real ceiling here, and it is a size limit rather than a row limit.