Rendered at 12:45:01 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
gettalong 1 days ago [-]
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.
jamessb 23 hours ago [-]
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].
theyre the AI todo app: sufficiently complex and mildly useful. will fail when real use case outstrips its minimum depth.
pdfmergely 6 hours ago [-]
[flagged]
pdfmergely 1 days ago [-]
[flagged]
hasudon7171 1 days ago [-]
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.
pdfmergely 7 hours ago [-]
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.
pmb_developer 21 hours ago [-]
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.
pdfmergely 7 hours ago [-]
[dead]
1 days ago [-]
sscaryterry 1 days ago [-]
Where is the company registered? None of these details are on your website.
pdfmergely 1 days ago [-]
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).
sscaryterry 1 days ago [-]
No one is going to take your word at face value. Assume people don't know how to open the developer tools.
pdfmergely 1 days ago [-]
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.
sscaryterry 1 days ago [-]
I don't know the answer honestly :) Just giving you the feedback I got before!
pdfmergely 8 hours ago [-]
Thank you
fp64 1 days ago [-]
Which library did you compile to WASM for this? I doubt this is a from scratch implementation of full PDF
pdfmergely 7 hours ago [-]
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.
steveharrison 1 days ago [-]
Love the idea, but would help trustworthiness if the design looked a little less vibe-coded.
pdfmergely 1 days ago [-]
[dead]
kewop 15 hours ago [-]
I cannot be the only one expecting a github repo on the website, right?
pdfmergely 7 hours ago [-]
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.
vedant_getbags 18 hours ago [-]
kindly improve the SEO to not end up in the vibecoded graveyard
pdfmergely 7 hours ago [-]
Point well taken. I appreciate it. It is being worked on .
jimjimjim 1 days ago [-]
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?
pdfmergely 1 days ago [-]
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.
pixel_popping 18 hours ago [-]
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.
pdfmergely 7 hours ago [-]
[dead]
1 days ago [-]
pdfmergely 1 days ago [-]
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.
da-x 1 days ago [-]
Perhaps you can also provide a Tauri-based independent downloadable app.
However, there are older tools that do this, such as BentoPDF (which is also open source) [1].
[1]: https://www.bentopdf.com/
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.
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.