Why is it that everyone now duplicates/vibe-codes PDF tool websites? It seems that there is one new each week for about half a year now with none providing any outstanding features over the others.
This one's website (and a dead comment replying to you) suggests that processing the PDF in the browser, rather than uploading to a server, is a point of differentiation.
However, there are older tools that do this, such as BentoPDF (which is also open source) [1].
Would you consider open-sourcing the client-side code? For privacy-focused PDF tools, that seems like the easiest way to make the “no upload” claim more trustworthy.
Fair point, I'll add an About/Contact page with who's behind it.
It's a small solo project; there's no company entity yet, but also no account or server, so nothing of yours is collected — files are processed in your browser and never leave your device (verifiable in the Network tab).
A good point . open the Network tab" isn't a real answer for most people, and "trust me" isn't either.
Two things that don't depend on either:
(1) the offline test is something anyone can do ,load the page, turn off your wifi, and the tools keep working, which they couldn't if they relied on a server;
(2) the site ships a Content-Security-Policy that blocks outbound connections, so it's the browser enforcing it, not my word. The real fix for trust is open-sourcing it and getting a third-party audit, which is on my list.
Our merge is page-level, not form-aware. We copy the pages (including the visual appearance of form fields), but we don't merge the PDFs' AcroForm dictionaries.
As a result, form fields typically aren't fillable after merging, and field name conflicts aren't an issue, so we don't rename fields.
We use @cantoo/pdf-lib (a maintained fork of pdf-lib) running entirely client-side in a Web Worker, so all processing happens locally in the browser and no files leave the user's device.
OP, you already know your website will end up in the graveyard, I just don't understand how anyone can still put up the same exact template as the last 100K viby websites released, it's literally a prompt away to have an original design, type that prompt, PLEASE.
Author here. Quick note on how the "no upload" claim actually works, since it deserves scrutiny.
There's no upload endpoint to send files to. When you pick a file, the browser hands the app the bytes directly; the work runs in a Web Worker on your device, with WebAssembly for the heavier parts like encryption. The finished PDF is built locally and downloaded. The page is also locked down with a strict CSP so file data has no network path out — you can open the Network tab and confirm nothing leaves while you work. After the first load it works fully offline, which is the easiest proof.
The honest tradeoff: because everything runs on your device, very large files depend on your machine's memory and a phone won't match a desktop. We process a page at a time to keep memory in check.
Tools today: merge, split, reorder, rotate, delete/extract pages, compress, watermark, page numbers, protect/unlock. Free, no sign-up. Would love feedback on what to add next.
However, there are older tools that do this, such as BentoPDF (which is also open source) [1].
[1]: https://www.bentopdf.com/
It's a small solo project; there's no company entity yet, but also no account or server, so nothing of yours is collected — files are processed in your browser and never leave your device (verifiable in the Network tab).
Two things that don't depend on either: (1) the offline test is something anyone can do ,load the page, turn off your wifi, and the tools keep working, which they couldn't if they relied on a server; (2) the site ships a Content-Security-Policy that blocks outbound connections, so it's the browser enforcing it, not my word. The real fix for trust is open-sourcing it and getting a third-party audit, which is on my list.
Appreciate you pushing on this.
And what pdf toolkit do you use?
As a result, form fields typically aren't fillable after merging, and field name conflicts aren't an issue, so we don't rename fields.
We use @cantoo/pdf-lib (a maintained fork of pdf-lib) running entirely client-side in a Web Worker, so all processing happens locally in the browser and no files leave the user's device.
There's no upload endpoint to send files to. When you pick a file, the browser hands the app the bytes directly; the work runs in a Web Worker on your device, with WebAssembly for the heavier parts like encryption. The finished PDF is built locally and downloaded. The page is also locked down with a strict CSP so file data has no network path out — you can open the Network tab and confirm nothing leaves while you work. After the first load it works fully offline, which is the easiest proof.
The honest tradeoff: because everything runs on your device, very large files depend on your machine's memory and a phone won't match a desktop. We process a page at a time to keep memory in check.
Tools today: merge, split, reorder, rotate, delete/extract pages, compress, watermark, page numbers, protect/unlock. Free, no sign-up. Would love feedback on what to add next.