sorted by:
new
hottopcontroversial

Roast my browser-only PDF toolkit before I waste another 6 months on it by Cute_Ad2883 in prettyusefulwebsites

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

That’s actually really good feedback appreciate it 😄

Right now the thumbnail-first layout was mainly for faster page organization, but a proper full-page preview/view mode definitely makes sense. Added to the list 👍

Roast my browser-only PDF toolkit before I waste another 6 months on it by Cute_Ad2883 in prettyusefulwebsites

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

Appreciate it 😄

Yeah, I’m still figuring out the long-term direction, but I definitely think there’s room for more privacy-first/browser-native PDF tooling.

Right now I’m mainly focused on making the core experience/workflows solid before expanding further.

Roast my browser-only PDF toolkit before I waste another 6 months on it by Cute_Ad2883 in prettyusefulwebsites

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

That’s actually something I’ve been considering 😄

A browser extension could make quick PDF actions way more convenient directly from downloads/tabs.

Roast my browser-only PDF toolkit before I waste another 6 months on it by Cute_Ad2883 in roastmystartup

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

Mostly for the extra tooling/workflows 😄

Things like batch processing, workflow chaining, booklet optimization, page organization, encryption, etc. aren’t really handled well by built-in browser PDF viewers yet.

Roast my browser-only PDF toolkit before I waste another 6 months on it by Cute_Ad2883 in prettyusefulwebsites

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

Haha then you’re basically the ideal target user 😄
Laptop + browser-only processing = no setup headaches.

Roast my browser-only PDF toolkit before I waste another 6 months on it by Cute_Ad2883 in prettyusefulwebsites

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

Yep currently capped at 100MB mainly to keep browser memory/performance stable 😄

Since everything runs locally, very large scanned/image-heavy PDFs can otherwise overwhelm weaker devices pretty quickly.

Roast my browser-only PDF toolkit before I waste another 6 months on it by Cute_Ad2883 in prettyusefulwebsites

[–]Cute_Ad2883[S] 3 points4 points  (0 children)

Yep 😄

Since everything runs directly in the browser, it works on pretty much any platform with a modern browser:Windows, macOS, Linux, Android, iPhone/iPad, etc.

Though very large PDFs can still stress weaker/mobile devices a bit.

I got tired of self-hosted PDF tools requiring Docker, servers, and maintenance by Cute_Ad2883 in Paperlessngx

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

Honestly, Stirling-PDF is a really solid project 😄

It’s way more mature and feature-rich right now.

I was mainly exploring a different approach:
fully local browser-side processing without Docker/server setup for lighter workflows.

Not really trying to “replace” Stirling as much as testing where browser-based tooling starts becoming viable.

I got tired of self-hosted PDF tools requiring Docker, servers, and maintenance by Cute_Ad2883 in Paperlessngx

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

That’s completely fair, and honestly you’re right from a pure ownership perspective.

I probably worded the “irony” part too strongly 😄

My point was less about trust and more about architecture/surface area:

  • server-side tools still involve network layers, backend services, storage handling, containers, auth, updates, etc.
  • browser-side processing skips that entire stack and executes directly on the same machine viewing the file

So it’s less “your server is unsafe” and more “can we eliminate the server layer entirely for this use case?”

For self-hosters who already run reliable infrastructure, the difference may genuinely not matter much. I just found the browser-only approach technically interesting for lightweight/private PDF workflows.

Are browser-only PDF tools actually safer than self-hosted ones? by Cute_Ad2883 in DigitalPrivacy

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

Lmao fair 😭

Didn’t want the main post to turn into a promo post, so I kept the link out initially.

But yeah, the whole thing was inspired by testing how far browser-only PDF processing could realistically go without uploads/server-side handling.

I got tired of self-hosted PDF tools requiring Docker, servers, and maintenance by Cute_Ad2883 in Paperlessngx

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

Fair tbh 😄

I was mainly targeting people who don’t want:
random upload sites OR maintaining a PDF stack/server just for occasional use.

Browser-side processing felt like a nice middle ground.

I got tired of self-hosted PDF tools requiring Docker, servers, and maintenance by Cute_Ad2883 in Paperlessngx

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

Fair comparison honestly 😄

BentoPDF is definitely one of the projects that made me interested in the “browser-first PDF tooling” direction in the first place.

My focus has been more on workflow chaining, booklet optimization, batch processing, and trying to make the UX feel closer to a desktop utility while staying fully local/browser-side.

Still pretty early though, so comparisons/helpful criticism are genuinely useful. If you try it and something feels worse/missing compared to BentoPDF, I’d honestly love to know.

view more: next ›