pdf-lib's ignoreEncryption flag does not skip encryption, it hands you a broken PDF

A developer writing on dev.to has published a list of the four things that actually break when you do PDF manipulation entirely in the client, and the first one is owner-password encryption ^[4][8]. It matters because the library's own escape hatch does not fail loudly: according to the post, `ignoreEncryption: true` gets you past the exception and returns an object that is structurally incomplete, which then merges into a file that opens to blank pages or does not open at all ^[6][7]. The pitch for client-side processing is genuinely good. pdf-lib takes an ArrayBuffer, gives you pages as objects and hands back bytes, so there is no upload, no server and no retention policy for anyone to trust, and the happy path is roughly fifteen lines ^[1][2]. Then the input arrives from a bank. A PDF can carry two passwords: a user password that stops the file opening at all, which users understand, and an owner password that lets anyone read the document while restricting what can be done to it ^[3]. Files from banks, insurers and government portals very often carry one, and nothing in the viewer tells you ^[4]. pdf-lib refuses these outright with "Input document to `PDFDocument.load` is encrypted." ^[5]. That refusal is the library behaving well. The flag that suppresses it is the defect surface, because the operation reports success and the output is garbage ^[7]. This is the distinction worth internalising. An exception is a test you can write. A structurally incomplete document that serialises without complaint is a data-integrity failure that only shows up in the user's hands, and the post notes that plenty of online PDF tools take exactly this shortcut: you upload a protected file, the spinner runs, you get a download, and the result is broken with no explanation, because from the tool's point of view nothing failed ^[8]. The suggested handling is to catch the load error, check whether the message mentions encryption, and raise a user-facing error telling the person to remove the protection in the application that produced the file ^[9]. Worth noting what that check is made of: it is string-matching on a library error message, so it survives only as long as pdf-lib phrases the error the same way ^[9]. Pin the version. The author's framing is that this is a worse-looking outcome and a much better one, and that "I can't do this, here's why" beats a corrupted file ^[10]. The same shape recurs in the other three failures. The memory ceiling gives you nothing to catch at all: every copy of the document lives in the tab, a 300-page scan at 300 dpi runs to a few hundred megabytes before you have done anything useful, and on mobile the tab simply dies with no exception and no `onerror` ^[11]. Hence a size guard before parsing rather than after, set at 100 MB in the example, with the error message naming PDFsam or Stirling PDF as the tool that will actually do the job ^[12]. Note that the guard sits below the size of the document class most likely to kill the tab, which is the point ^[18]. Sequential processing helps below the ceiling: merging ten files one at a time uses a fraction of the peak of merging them in parallel ^[13]. Compression is the same problem in expectation form. Scans are photographs, about 95 percent image weight, and re-encoding or dropping 600 dpi to 200 can cut an order of magnitude while staying readable ^[14]. Word-processor output has almost nothing to win, and a tool promising 80 percent off one of those is rasterising your pages, which quietly ends selectable, searchable, accessible text ^[15]. The proposed detector is one line: fewer than 50 extracted characters per page means you are looking at a scan ^[16].