For scripts, the same engine is in the bindery-pdf package: npx bindery-pdf split works from a terminal with a current Node.js, and the Docker image runs it with a folder mounted at /work; the library’s split and extract functions take a Uint8Array and return one. Pages are copied unchanged in every mode, so text stays selectable and scans keep their resolution. Files above 200 MB open in big-file mode in the browser, which streams the document and splits by page count with a few megabytes in use. Nothing is uploaded, and the original is never modified.
How it works
- Open Bindery in Firefox or Chrome and drop the PDF into Split
- Choose every page, every N pages, at bookmarks, or under a size
- Download the ZIP — or use npx bindery-pdf split in a terminal
Questions people ask
Can the CLI split under a size limit?
The CLI splits by page count; the size-based mode, which writes and measures each part, is in the browser app. For a size-capped delivery from a script, split by pages and check sizes, or run the browser tool once and reuse its ZIP.
How is this different from pdfseparate?
pdfseparate writes one file per page and nothing else. Bindery adds even chunks, chapters at bookmarks named after their titles, and parts under a size limit, previews the plan on a page board, and delivers everything as one ZIP without touching the page content.
Is the browser version any slower than the tools in my repos?
For ordinary documents the difference is not noticeable; the work runs in a background worker inside the browser. Very large scans stream in big-file mode rather than loading whole, so memory use stays low even on a modest machine. Any job can be cancelled midway.