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.
Which library did you compile to WASM for this? I doubt this is a from scratch implementation of full PDF
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!
Love the idea, but would help trustworthiness if the design looked a little less vibe-coded.
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.
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.