How We Moved PDF Processing from Server to Browser (and Killed OOM Crashes)

This is a real story from today. No theory — just a debugging session that went from a mysterious 403 , to a silent 500 , to discovering our server was dying from memory exhaustion on every PDF export. The Setup We run Ultimate Tools — a collection of 24 free, privacy-first browser-based utilities. One of our tools is a PDF Studio : organize pages, add watermarks, apply digital signatures (eSign), set metadata, compress, and split documents. The export flow was simple: User uploads a PDF → saved to server temp directory User applies operations (signatures, reordering, watermarks) User clicks Download → POST /api/pdf/apply/ → server processes with pdf-lib → returns the PDF Worked perfectly in local dev. On production (Hostinger Node.js hosting), it completely broke. Step 1: The 403 That Made No Sense The first error was a 403 with a 60ms response time. POST https://ultimatetools.io/api/pdf/apply/ [ HTTP / 2 403 60ms] Response headers: server: hcdn content-type: text/plain content-length