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.
A fair question. There is no from scratch PDF engine here. It is @cantoo/pdf-lib, a maintained fork of pdf-lib, running client side in a Web Worker, with WebAssembly handling the heavier parts such as encryption. I am happy to go deeper on any part of it.
Ofc not the only one, and the expectation is reasonable. A repo is coming, and for a tool like this it arguably should have been there from the start. Thank you for the nudge.
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.
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].
[1]: https://www.bentopdf.com/
theyre the AI todo app: sufficiently complex and mildly useful. will fail when real use case outstrips its minimum depth.
To me, it looks like a design generated by AI. It had exactly the same vibe as those kinds of sites I see all the time.
I appreciate the directness, and you are right.
The design has not yet earned trust, and that is on where I am working in.
For a tool people hand documents to, looking trustworthy and being trustworthy need to line up. Thank you for saying it plainly.
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.
Where is the company registered? None of these details are on your website.
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).
No one is going to take your word at face value. Assume people don't know how to open the developer tools.
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.
Appreciate you pushing on this.
I don't know the answer honestly :) Just giving you the feedback I got before!
Thank you
Which library did you compile to WASM for this? I doubt this is a from scratch implementation of full PDF
A fair question. There is no from scratch PDF engine here. It is @cantoo/pdf-lib, a maintained fork of pdf-lib, running client side in a Web Worker, with WebAssembly handling the heavier parts such as encryption. I am happy to go deeper on any part of it.
Love the idea, but would help trustworthiness if the design looked a little less vibe-coded.
I cannot be the only one expecting a github repo on the website, right?
Ofc not the only one, and the expectation is reasonable. A repo is coming, and for a tool like this it arguably should have been there from the start. Thank you for the nudge.
kindly improve the SEO to not end up in the vibecoded graveyard
Point well taken. I appreciate it. It is being worked on .
Question about merging: How do you handle merging multiple pdf that have forms? Are the form fields renamed to prevent form field name clashes?
And what pdf toolkit do you use?
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.
Perhaps you can also provide a Tauri-based independent downloadable app.