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.
Show HN: PDFMergely – In-browser PDF tools that never upload your files
11–20 of 35 posts
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#12Question 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.
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#13Earlier quoted context omitted.
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…
I don't know the answer honestly :) Just giving you the feedback I got before!
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#14[deleted]
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#15Why 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.
[flagged]
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#16Why 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.
theyre the AI todo app: sufficiently complex and mildly useful. will fail when real use case outstrips its minimum depth.
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#17Author 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 dat…
Perhaps you can also provide a Tauri-based independent downloadable app.
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#18Which library did you compile to WASM for this? I doubt this is a from scratch implementation of full PDF
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#19To 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.
Re: Show HN: PDFMergely – In-browser PDF tools that never upload your files
#20Why 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].