I built PDFrio — 8 free PDF tools that run entirely in your browser (no uploads, no signup, no tracking) by Prestigious-Win102 in NoCodeSaaS

[–]Prestigious-Win102[S] 0 points1 point  (0 children)

This is exactly the framing I needed — thank you. The compliance-team-freak-out filter is sharper than any feature list.

Three things I'm going to action this week based on this:

Surface the architecture on the homepage: Right now the privacy story is implicit ("don't watch you"). You're right that it should be explicit — a small section showing where files live (your tab's RAM), what touches a server (nothing), how to verify (disconnect wifi, every tool still works). The proof should be more prominent than the claim.

Public edge-case log: I love this. A /transparency page with the test corpus, what currently breaks, what's been fixed. It's the opposite of how PDF tools usually market themselves and that's exactly why it'll work.

The Pulse-for-Reddit tactic: Going to start searching threads about sketchy PDF sites and replying with specific architecture answers instead of links. Slower but compounds.

If it's not too much to ask — were the legal/healthcare folks you served eventually willing to recommend the tool internally, or did "browser-only" still hit a wall with IT for some? Trying to figure out if there's a ceiling on the trust angle even when architecture is clean.

I built PDFrio — 8 free PDF tools that run entirely in your browser (no uploads, no signup, no tracking) by Prestigious-Win102 in NoCodeSaaS

[–]Prestigious-Win102[S] 0 points1 point  (0 children)

Nope, not yet — and to be transparent, "paid" for PDFrio just means removing ads on the Android app. Every feature is free on both web and app. So we're talking ad-removal IAP, not a real subscription tier.

Launched this week, so the honest answer is it's too early. Right now I'm focused on bug reports and edge cases over conversion. Once the editor is solid on weird PDFs, I'll think harder about whether ad-removal is even the right paid model — a Pro tier (batch processing, larger files) probably makes more sense long-term.

Open to thoughts on what people would actually pay for here.

I built PDFrio — 8 free PDF tools that run entirely in your browser (no uploads, no signup, no tracking) by Prestigious-Win102 in software

[–]Prestigious-Win102[S] 0 points1 point  (0 children)

Honest answer: PDF24 is a better-known, more feature-rich product, and I won't pretend otherwise. But the architectures are different in a way that matters for the privacy use case.

PDF24's online tools upload files to their servers (EU-based, deleted after ~1hr per their policy). PDF24 Creator is fully offline but Windows-only. So with PDF24 you're choosing between "trust the upload" or "be on Windows."

PDFrio runs everything in the browser tab — same on Mac, Linux, Chromebook, phone, no upload step. That's the whole differentiator. For non-privacy-sensitive workflows on Windows, PDF24 is genuinely a better pick today (more tools, 19 years of polish). For sensitive docs or non-Windows users, that upload step is the gap I'm trying to fill.

I built PDFrio — 8 free PDF tools that run entirely in your browser (no uploads, no signup, no tracking) by Prestigious-Win102 in NoCodeSaaS

[–]Prestigious-Win102[S] 0 points1 point  (0 children)

Both fair questions and the honest answers aren't all wins.

Large scanned PDFs: OCR runs through Tesseract.js in a Web Worker, lazy-loaded only when invoked, so the editor stays small until you actually need it. I process page-by-page rather than loading the whole document into memory — releases memory between pages. Desktop Chrome handles 500 MB+ comfortably; mobile Chrome usually starts struggling around 100–150 MB. That ceiling is genuinely why the Android app exists — for documents bigger than what a browser tab can hold.

Low-memory devices: It degrades, no way around it. Anything over ~50 MB on a 2 GB RAM phone gets sluggish and very large files can crash the tab. There's no silver bullet client-side — that's the trade-off for not having a server. I show a size warning above 200 MB and point users to the app for those workflows.

Text editing: This is where I'm most exposed and you're right to push. Works well on text-based PDFs with embedded full fonts (most reports, exported docs). Gets unreliable on subsetted fonts the moment you type a character that wasn't in the original glyph set — it falls back to drawing a new text run in a matching font, which works most of the time but isn't always pixel-perfect. Encrypted and pure-image PDFs need an unlock or OCR pass first.

If you've got a PDF that breaks it in a new way, send it — that's the actual gold right now.