A PDF tool that forgets everything
Why my PDF toolbox stores nothing, logs nothing, and keeps its scratch files in memory.
I keep PDFs I would rather not upload to a stranger’s website: statements, forms, scans. So I built a small toolbox for myself that merges, splits, rotates, compresses, watermarks and unlocks them.
The interesting part was not the tools. It was deciding what the server should remember. The answer I settled on is nothing.
- Files are never written to the app’s disk. Heavy jobs, like compression, use scratch space in memory that is deleted when the request ends.
- Access logs are switched off, so even the file names never land anywhere.
- Every response says not to cache it, and the pages ask search engines to ignore them.
- The container’s own filesystem is read-only.
The app also checks who is asking on every request. Two locks, because the cost of a mistake is high and the second lock is cheap.
A later pass was about telling the truth on the page. Every tool runs on the server, so the page now says so plainly instead of hinting that your browser does the work. It also checks each file when you drop it in, shows the page count, asks for a password only when a PDF needs one, and clears that password the moment the job is done.
The lesson I keep relearning: privacy is easiest when it is a design constraint from the first commit, not a feature added later.