Rendered at 12:28:17 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
hasudon7171 18 seconds 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.
gettalong 2 hours 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.
cyanydeez 2 hours ago [-]
theyre the AI todo app: sufficiently complex and mildly useful. will fail when real use case outstrips its minimum depth.
pdfmergely 2 hours ago [-]
[flagged]
fp64 46 minutes ago [-]
Which library did you compile to WASM for this? I doubt this is a from scratch implementation of full PDF
4 hours ago [-]
sscaryterry 5 hours ago [-]
Where is the company registered? None of these details are on your website.
pdfmergely 5 hours 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 5 hours ago [-]
No one is going to take your word at face value. Assume people don't know how to open the developer tools.
pdfmergely 5 hours 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 2 hours ago [-]
I don't know the answer honestly :) Just giving you the feedback I got before!
steveharrison 5 hours ago [-]
Love the idea, but would help trustworthiness if the design looked a little less vibe-coded.
pdfmergely 5 hours ago [-]
[dead]
jimjimjim 3 hours 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 2 hours 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.
2 hours ago [-]
pdfmergely 6 hours 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 58 minutes ago [-]
Perhaps you can also provide a Tauri-based independent downloadable app.
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.