Generating a PDF is easy. Proving it's the original is the part nobody ships.

I write a lot of code that spits out PDFs. Invoices, lab-style reports, a certificate thing for a side project. And honestly that part is solved. You pick a lib, throw data at it, a file comes out. Done in an afternoon.

Then someone forwards you a PDF and goes "is this the one we actually sent, or did somebody edit a number in it?" and you just don't have an answer. You're staring at a file. It looks fine. It's always going to look fine. A tampered PDF looks exactly as legit as the real one, that's the whole problem.

So I went looking. Digital signatures (PAdES, the cert stuff) exist, but try telling the person on the receiving end to install a cert chain and validate it in some desktop reader. Not happening. The recipient is usually not a dev. They got an email with an attachment, that's it.

What I actually wanted was dumber: whoever receives the file should be able to confirm, with zero setup, that nothing in it changed since it left my server.

So I built Renderly

You make the PDF one of two ways. Draw it in a visual editor (Figma-ish, drag stuff around), or hit an API with JSON. The editor's handy when a non-dev needs to tweak a template, the API's there when it's all automated. Whichever fits.

The render engine is native PDFKit, not headless Chrome. I went back and forth on this and I'm glad I skipped the browser. Spinning up Chromium to print-to-PDF means you're suddenly fighting print CSS at 2am, page-break weirdness, fonts that render slightly different across machines, plus a cold-start tax on every doc. Native means the bytes are deterministic. Same input, same output, down to the byte. Which matters a lot for the next bit.

Every PDF comes out sealed. I take the SHA-256 of the actual bytes and stamp a QR onto the doc. There's a public page at /verify. No login, no account, nothing. The recipient drops the file in (or scans the QR) and it tells them who issued it and whether a single byte moved since it was generated. Somebody opened it in a PDF editor and bumped an amount? Hash won't match, verify says so.

Now, I want to be precise here, because it's easy to oversell and a dev will (rightly) call you on it. This does not stop anyone from faking a PDF. Anybody can fake a PDF, that's trivial. What changes is the fake becomes detectable, and the person holding the real file can prove theirs is the original. Falsification doesn't become impossible. It becomes catchable. That's the honest version and it's still useful in practice.

Where it actually comes up:

• A landlord forwards a "signed" agreement with one clause quietly reworded. Verify the original, the edited one fails.
• An invoice gets intercepted and the bank details swapped before it hits the client. Real scam, happens constantly. Client checks against verify, the swapped one doesn't match.
• A discount voucher where the number's been bumped. Same deal.

None of those need the recipient to have an account or trust me. They check the file against a public page and either it matches or it doesn't.

Solo thing, still beta, I'm a Brazilian dev building it nights and weekends. Free up to 500 docs a month, no card.

Site: https://getrenderly.vercel.app

And the verifier you can poke without signing up for anything, which is honestly the part I'm proudest of: https://getrenderly.vercel.app/verify

If you've solved "prove this file is the original" some other way that a normal recipient can actually use, I want to hear it. I looked for a while before building this and came up mostly empty.