BentoPDF is a JavaScript, browser-based PDF toolkit that merges, edits, converts, and processes documents entirely on the client, and it is aimed at individuals and teams who need those document workflows without sending files to a third-party service.

What it is

BentoPDF is a self-hostable, privacy-first PDF toolkit written in JavaScript and licensed under AGPL-3.0, with a dual-licensing option for commercial use. All manipulation, editing, merging, and processing of PDF files happens in the browser, and the project states that no server-side processing is required, which keeps files inside the operator's own infrastructure. It is documented through a VitePress site at bentopdf.com and carries over 50 tools, grouped in the README into Organize and Manage PDFs, Edit and Modify PDFs, Convert to PDF, Convert from PDF, and Secure and Optimize PDFs.

The concrete problem it solves is the default pattern of PDF work: personnel upload sensitive documents to a remote conversion or editing service, where the file leaves the organisation and the tooling is owned by a vendor. BentoPDF replaces that upload-and-wait model with an application the user or the IT team can host themselves, so the processing libraries run in the browser tab rather than on someone else's machine. Within the JavaScript and Docker self-hosting ecosystem, it is positioned as an alternative to server-side PDF processing, and its topic list tags it explicitly against adobe-acrobat.

Key capabilities

• Over 50 tools across five README categories: Organize and Manage PDFs, Edit and Modify PDFs, Convert to PDF, Convert from PDF, and Secure and Optimize PDFs.
• Client-side merging, editing, and processing of PDF files with no server-side processing step.
• Conversion and recognition features reflected in the topic list, including jpgtopdf, pdf-ocr, pdf-converter, pdf-editor, pdf-viewer, and pdf-generation.
• Digital signatures, which the README notes require a CORS proxy.
• Custom branding, the ability to disable specific tools, and the ability to disable the GitHub star counter.
• WASM configuration together with documented air-gapped and offline deployment.
• Static hosting support for Netlify, Vercel, and GitHub Pages.

Who uses it and how

• Teams that cannot send contracts or personal data to external converters deploy the container themselves, using the recommended Docker Compose or Podman Compose route.
• Linux administrators running rootless container infrastructure can deploy it as a Podman Quadlet with systemd integration.
• Organisations on restricted networks use the air-gapped and offline deployment path, with WASM configuration standing in for CDN-hosted components.
• Operators with existing web infrastructure follow the self-hosting guides for Nginx, Apache, Cloudflare, AWS, and Hostinger, or publish the static build to Netlify, Vercel, or GitHub Pages.
• The project has drawn roughly 15,573 stars and 1,338 forks, and its hacktoberfest topic marks it as a target for seasonal open-source contributions.

Getting started

The README recommends running BentoPDF with Docker Compose or Podman Compose using the published ghcr.io/alam00000/bentopdf-simple image, and it can also be used as a hosted service at bentopdf.com or deployed as a static build on Netlify, Vercel, or GitHub Pages.

How it compares

BentoPDF carries the adobe-acrobat topic tag, which places it in the same functional territory as Adobe's PDF tooling, but the facts provided contain no side-by-side list of paid products it replaces, so a feature-level comparison cannot be drawn here. What can be compared is the licence and cost model: BentoPDF is dual-licensed as free AGPL-3.0 for projects whose source code is public, or as a one-time $79 commercial licence with unlimited devices and users, lifetime updates, and no AGPL obligations. Because processing runs in the browser and the application is self-hostable, document data stays under the operator's control rather than being transferred to a vendor, which is the axis on which the project positions itself.

When to use it — and when not

Self-hosters must operate either a static web host or a container, and because everything runs client-side no database, application server, or SMTP service is required; the recommended path is Docker Compose or Podman Compose. Two caveats deserve attention: digital signatures depend on a CORS proxy, and the AGPL-licensed processing libraries are pre-configured through CDN URLs rather than bundled, so genuinely air-gapped deployments must follow the WASM and offline guidance. Teams building proprietary, closed-source products should not take the AGPL-3.0 path, and with 156 open issues on the tracker, anyone wanting a zero-maintenance tool should review the VitePress documentation before committing.