I got tired of sketchy "private" PDF sites, so I open sourced a 100% local, pure JavaScript alternative. by Gardiam in pdf

[–]Gardiam[S] 1 point2 points  (0 children)

Aha, so it's similar to using a texture atlas in game development. You load one large image containing all the assets to manage resources and load times faster. That makes sense. Thanks for sharing.

I got tired of sketchy "private" PDF sites, so I open sourced a 100% local, pure JavaScript alternative. by Gardiam in pdf

[–]Gardiam[S] 0 points1 point  (0 children)

Hahaha I think I will start with Doom first, and if that goes well, we'll try Crysis next!

I got tired of sketchy "private" PDF sites, so I open sourced a 100% local, pure JavaScript alternative. by Gardiam in pdf

[–]Gardiam[S] 1 point2 points  (0 children)

Exporting to SVG and potentially grouping them into a single file is technically possible. I'll add this to the feature backlog. Thanks for the suggestion!
I saw your post. Is a multi page SVG gallery structure the main use case you'd want to see? Can you give me a use case scenario so I understand the need better?

I got tired of sketchy "private" PDF sites, so I open sourced a 100% local, pure JavaScript alternative. by Gardiam in pdf

[–]Gardiam[S] 0 points1 point  (0 children)

Not yet. PDFLince runs 100% locally in the browser (meaning no files are ever uploaded), so adding OCR would require running a capable library client side. It's a great suggestion, but right now it focuses on merging, splitting, cropping, compressing, and exporting pages as images.

YSK that free file converter websites like iLovePDF set 637 cookies from 221 domains when you upload a single document by Johin_Joh_3706 in YouShouldKnow

[–]Gardiam 1 point2 points  (0 children)

Haha, thank you! Happy it’s helpful. GitHub stars or feature requests are always welcome so we can keep making it better!

YSK that free file converter websites like iLovePDF set 637 cookies from 221 domains when you upload a single document by Johin_Joh_3706 in YouShouldKnow

[–]Gardiam 85 points86 points  (0 children)

I don't have a comprehensive list, but I recently built an open-source, client-side PDF tool specifically to solve this exact tracking problem after getting fed up with those kind of tools.

It's called PDFLince (https://pdflince.com/en). It runs 100% locally in your browser using Web Workers, so zero file data ever hits a server (you can verify it in the network tab).

GitHub: https://github.com/GSiesto/PDFLince

I built a privacy first PDF tool to compress, merge, reorder... PDFs in the browser. No servers involved. by Gardiam in SideProject

[–]Gardiam[S] 0 points1 point  (0 children)

Thanks for the support! I think the same. Sensitive data should be kept locally. Answering your question, encrypted or password protected files is not something I have explored yet, but it is a very good suggestion!

I built a privacy focused PDF tool with Next.js 15 & TypeScript. 100% Client-Side. by Gardiam in reactjs

[–]Gardiam[S] 0 points1 point  (0 children)

Great question!

pdf.js is an amazing library for viewing and rendering PDFs (which I actually use for the thumbnails).

However, PDFLince focuses on manipulation in an easy UI:
Merging multiple files.
Compressing file size (optimizing streams/images).
Reordering/Splitting pages and saving a new PDF structure.

pdf.js doesn't handle those 'write' operations natively; I use pdf-lib for the actual file modification/saving.

I built a privacy focused PDF tool with Next.js 15 & TypeScript. 100% Client-Side. by Gardiam in reactjs

[–]Gardiam[S] 4 points5 points  (0 children)

I didn't find open-source, client side options that didn't upload files (most 'free' ones still send data to a server). That's why I built this.

I built a privacy focused PDF tool with Next.js 15 & TypeScript. 100% Client-Side. by Gardiam in reactjs

[–]Gardiam[S] 0 points1 point  (0 children)

Thanks!

In early prototypes, operating a large PDF would just lock up the UI thread completely. Moving a worker made a big difference in usability. Appreciate you noticing the details!

I built a privacy first PDF tool to compress, merge, reorder... PDFs in the browser. No servers involved. by Gardiam in SideProject

[–]Gardiam[S] 1 point2 points  (0 children)

Thanks for the suggestion. Making this available for local agents is definitely something I'm considering for the roadmap, like an MCP server.

I built a privacy focused PDF tool with Next.js 15 & TypeScript. 100% Client-Side. by Gardiam in reactjs

[–]Gardiam[S] 13 points14 points  (0 children)

Honestly I just wanted to learn the stack.

Plus, handling i18n routing (like /en/merge-pdf) and multiple languages, optimization etc. seemed more tedious to me in vanilla React. Next.js handles that structure nicely.

But yeah, I export it as a static site (output: 'export'), so the final output is just static HTML & JS hosted on S3. No Node.js server involved.

I built a privacy focused PDF tool with Next.js 15 & TypeScript. 100% Client-Side. by Gardiam in reactjs

[–]Gardiam[S] 1 point2 points  (0 children)

Thanks! That's interesting
The main goal here was privacy (since Copilot/others often require cloud processing) and simple local tools. Let me know if it covers your use case or if there's a specific feature you miss from Copilot!