A PDF SDK with no server in it
Every other PDF API in this space is a REST endpoint: your user’s document travels to a third party, is processed, and comes back. That is a fine design until the document is a medical record, a client’s bank statement or an unsigned contract — at which point “deleted after an hour” is a promise about someone’s conduct, not a limit on their access, and your compliance review has to reason about a vendor your user never chose.
This runs in the browser tab. No endpoint, no key, no upload.
npm i @diemdesk/pdf pdf-lib
import { merge, extractPages, info } from '@diemdesk/pdf';
const file = await input.files[0].arrayBuffer();
const { pages } = await info(file); // 12
const firstThree = await extractPages(file, '1-3');
const combined = await merge([fileA, fileB]);Nothing to declare
No subprocessor in your DPA, because there is no processor.
Nothing to meter
It runs on hardware your user already paid for.
No plan limit
File size is bounded by their memory, not our pricing.
What it does
| info(bytes) | page count, page sizes, title / author / producer |
| merge(files[]) | join documents in the order given |
| extractPages(bytes, sel) | keep only the pages you select |
| deletePages(bytes, sel) | drop the pages you select |
| rotate(bytes, opts) | turn pages, relative to their current rotation |
| removeMetadata(bytes) | clear title, author, producer, timestamps |
| splitEvery(bytes, n) | cut into fixed-size chunks |
| parsePageSelection(spec, n) | "1-3, 7, 12-" → page indices |
Page selections take either a string a person would type ('1-3, 7', '12-', 'all') or explicit one-based numbers. One-based going in, because that is what is printed on the page; zero-based internally, because that is what the PDF wants. That boundary lives in one tested function instead of being re-derived at every call site.
What it doesn’t do, on purpose
- Bookmarks and form fields through merge
- pdf-lib copies pages, not the document-level structures that point at them. A half-copied outline is worse than none.
- Encryption or password removal
- Not supported. We would rather say so than ship something that half-works.
- OCR, rasterisation, Office conversion
- These need heavy WASM or a server. Including them quietly would betray the whole point of the package.
- removeMetadata does not touch the page
- It clears the information dictionary. Text visible on the page stays visible — removing that is redaction, a far more careful operation.
The honest trade
Browser memory is not infinite, and this is synchronous work on the main thread unless you move it into a Worker. For files in the tens of megabytes that is a non-issue; for a 500MB scan it is not, and your UI should say so. We would rather you knew that before you shipped than after.
Not on npm yet
The package is built and tested, and the licence is still being settled — publishing under terms we would want to change later is the one mistake you cannot take back, because everyone who installed it keeps the terms they got. If you want it, say so and we will tell you the day it lands.
Tell us what you need