Your PDF API provider promises "secure processing." But their temp files sit on disk for 15 minutes while garbage collection runs. That's 15 minutes where a patient's medical records exist on infrastructure you don't control.
Most developers don't think about this. They shouldn't have to. But if you're generating PDFs with protected health information or personal data, the default architecture of most PDF APIs puts you at legal risk.
The Hidden Data Lifecycle
Here's what happens when you call a typical PDF API:
That temp storage step? It's where the problems start.
Most PDF APIs write your HTML to disk before rendering. Makes sense from an engineering perspective. Disk is reliable. If the worker crashes, the job can be retried. If there's a spike in traffic, jobs queue up nicely.
But that means your data exists in:
- The request payload (logged for debugging)
- The temp directory (waiting to be processed)
- The output file (waiting to be served)
- CDN caches (if they use one)
- Backup systems (if they have them)
Each copy is a liability.
GDPR Article 17: The Right to Erasure
GDPR gives EU residents the right to request deletion of their personal data. Article 17 is clear: when someone asks you to delete their data, you delete it. All of it.
But how do you delete data you can't find?
Temp files don't have user IDs attached. Request logs might be shipped to a third-party logging service. CDN caches have their own TTLs. Even if you delete the final PDF, fragments of the source data might exist in half a dozen places.
The regulation doesn't care about your architecture problems. It cares about outcomes. Can you prove, under audit, that you deleted every copy of that person's data?
If you used a PDF API that writes to disk, the honest answer is probably no.
And the fines aren't theoretical. GDPR penalties can hit 4% of global annual revenue. For a company doing $10M/year, that's $400K. For larger companies, the numbers get scary fast.
HIPAA's "Minimum Necessary" Standard
HIPAA has a similar problem, but with different language. The "minimum necessary" standard says you can only use or disclose the minimum amount of PHI (Protected Health Information) needed for a specific purpose.
Temp storage violates this principle.
If you're generating a PDF of a patient's lab results, the minimum necessary data is what appears in that PDF. Not what sits in a temp file for 15 minutes. Not what gets logged in request payloads. Not what might exist in backup systems you've never audited.
The standard is strict: PHI should only exist where it needs to exist, for as long as it needs to exist.
Fifteen minutes is too long. A temp directory is the wrong place.
And if that temp file gets exposed—through a misconfigured server, a vulnerable dependency, or a breach at your PDF provider—you're on the hook for breach notification. That means notifying every affected patient, notifying HHS, and potentially notifying media outlets if more than 500 people are affected.
The Audit Log Problem
Here's what makes this tricky: compliance isn't just about doing the right thing. It's about proving you did the right thing.
When an auditor asks how you handle PHI in PDF generation, you have two possible answers:
"We use a PDF API that writes to temp storage, then deletes those files within 15 minutes of processing."
"We use a streaming PDF API. The data exists only in memory during rendering. Nothing is written to disk. There's nothing to delete because we never stored it."
The first answer requires you to prove deletion happened. You need logs showing the temp file was created, logs showing it was deleted, and confidence that no copies exist elsewhere.
The second answer is simpler: we never had it.
"We never stored it" beats "we deleted it" every time. There's no audit trail to verify, no edge cases to worry about, no gaps in your deletion logic to explain.
Zero-Storage Architecture
The fix is to never write to disk in the first place.
Here's how a streaming architecture works:
The data flows through the system without stopping. Your HTML goes in, PDF bytes come out. Nothing touches disk. Nothing gets queued. Nothing gets cached.
When the request completes, the data is gone. Not deleted—just never stored.
This is how NeatPDF works. The architecture is simple:
- Your request hits our edge worker
- Chromium renders the HTML in memory
- The PDF streams back as the response body
- Request completes, memory is freed
No temp files. No cleanup jobs. No garbage collection windows. No copies sitting in places you can't audit.
Implementation
Here's what the code looks like:
import { NeatPDF } from '@neatpdf/sdk'
const client = new NeatPDF({ apiKey: process.env.NEATPDF_API_KEY })
// The response is a ReadableStream
const pdfStream = await client.generate({
html: patientLabResults,
format: 'A4',
})
// Stream directly to the client—no intermediate storage
return new Response(pdfStream, {
headers: {
'Content-Type': 'application/pdf',
'Content-Disposition': 'attachment; filename="lab-results.pdf"',
},
})The PDF never exists as a file on your server either. It streams from NeatPDF, through your server, to the client. The data is in flight, never at rest.
For HIPAA compliance, this matters. PHI "at rest" has different requirements than PHI "in transit." By keeping data in transit throughout the entire flow, you sidestep an entire category of compliance requirements.
Trade-offs
This architecture isn't free. There are trade-offs.
No retry on failure. If the render fails halfway through, you start over. Traditional temp-file systems can pick up where they left off. We can't.
No caching. Every request renders fresh. If you're generating the same PDF repeatedly, you're paying for each render. (Though if you're generating the same PHI document repeatedly, you probably have bigger problems.)
Memory pressure. Large documents consume memory during render. We handle this fine, but it means there's a practical limit to document complexity.
For most compliance-sensitive use cases, these trade-offs are worth it. The alternative is explaining to an auditor why patient data sat on a third-party server for 15 minutes.
If you're building something that handles PHI or personal data, the PDF generation step deserves scrutiny. Most APIs weren't designed with compliance in mind. They were designed to be reliable and fast. Those are good goals, but they're not sufficient when regulations are involved.