I built a PDF-to-JSON tool because I didn't trust the AI's output
A few weeks ago I had to pull transactions out of a stack of bank statements. I reached for an LLM, got clean-looking JSON back, and almost shipped it. Then I counted the rows: 47, when the statement actually had 52. It looked right, so I nearly trusted it.
That gap is why I built pdftojson.dev.
The easy part of getting data out of a PDF is the extraction. Libraries and LLMs both do that fine. The hard part is knowing when the output is wrong, because wrong output usually looks completely fine. On one invoice you catch it by eye. On ten thousand statements you don't, and a silently dropped row is a wrong number nobody notices until month-end.
So the tool does two things. There's a free in-browser converter that turns a PDF into JSON, Markdown, CSV, XML or text, with nothing uploaded since it parses locally. And there's an API for the harder jobs: OCR for scans, table extraction, and a bank-statement endpoint that reconciles its own output. It checks that opening balance plus credits minus debits equals the closing balance, or it flags the statement as not cleanly parsed.
It's live, there's a free tier, and the API is $29/mo.
Where I'd love feedback:
- Is "the tool checks its own work" actually a reason people would pay, or do developers assume they'll just verify it themselves anyway?
- The landing page leads with the reconciliation story. Is that too niche? Should it lead with the plain PDF-to-JSON use case instead?
- Pricing: $29/mo feels right for a solo dev, but I have no sense of where it should sit for a team.
Link: https://pdftojson.dev
Happy to answer anything about how it's built.
Bank statements and invoices are the classic hard cases - multi-page tables where the LLM merges or splits rows silently. The failure signature to watch: row counts that are internally consistent but do not reconcile against totals. Anything handwriting-heavy (receipts) fails loudly instead, which is almost better. The pattern that matters commercially: extraction confidence and correctness are uncorrelated, so a confidence score does not substitute for your reconciliation check.
Thanks for the kind words - glad it landed. One thought on the "sit with the pricing" plan: put a date on it. Pricing paralysis is a silent killer for solo founders, and a placeholder line like "from $29/mo, team pricing scales with volume" converts better than a blank section - you can always change it the day the data justifies it. If a second pair of eyes helps on the rewrite, happy to look: I run a paid developer API myself (different category, same go-to-market loop), so I've just been through exactly this. Good luck with the launch, watching pdftojson.dev with interest.
the 47-vs-52 row thing is such a perfect example of why AI verification is harder than it looks. the output doesn't just fail -- it fails in a way that passes the eyeball test. your reconciliation approach is smart because it gives you a mathematical check that doesn't rely on human attention. curious whether you've seen patterns in which document types the LLM struggles with most?
Congrats on shipping. Disclosure up front: I do landing page critique, so read this as a peer note rather than a customer one.
On your second question: as of this morning the page already answers it. The headline is "Turn any PDF into clean, structured JSON." and the fold never mentions a bank statement; the reconciliation story is the fourth block below the fold. Whether that changed after the exchange above or was always so, the lead is settled, so here is the most expensive thing on the first screen now: the right half of your converter card. It is a 588x399 px panel that says "Your output appears here." and nothing else, at the exact moment a visitor is deciding whether to trust your parser with a file. You already have the perfect filler further down the page, the "Invoice #1042" structured sample. Pre-fill the panel with it, label it "Sample output, drop your own PDF to replace it", and add a "try a sample invoice" link in the dropzone for people with no PDF to hand. That turns half the hero from dead space into your demo.
Three more, in order:
The page never states a price. This post says $29/mo; the landing page's text contains no dollar amount, and the API's whole presence above the fold is a 19-px "API" nav link and a "Sign in" box. Put "from $29/month" in the mid-page API teaser, and relabel "Sign in" to "Get API key". Your pricing page's own headline, "Pay for pages, not seats", is also the answer to the seat question above; the landing page just never says it.
Mobile: the header takes two rows (118 px), the "Sign in" box wraps to "Sign / in", the format tabs lose "XML" off the right edge, and the dropzone label lands at y=679 of 844. Collapse the nav to one row and the dropzone climbs to the middle of the screen.
One trust point, because your fold says "Nothing uploaded": the page loads PostHog's session recorder, 157 KB, with input masking off in the config it serves, and your privacy page describes "aggregate analytics". I did not test what it captures, but a developer with the network tab open will ask before dropping a bank statement. 470 of the page's 629 KB are analytics; the product's own JS is 6 KB.
I ran our full teardown on your page and published it, free, nothing owed: https://squint.page/sample-17/ The output-panel and pricing points are worked through with exact rewrites there.
Really interesting idea! The fact that the tool validates its own output is definitely valuable, especially for financial documents where a missing transaction can cause serious problems.
I don't think the reconciliation story is too niche—it actually makes the product stand out from generic PDF-to-JSON tools. You could lead with the broader PDF-to-JSON use case while quickly highlighting validation and reconciliation as your key differentiator.
As for pricing, $29/month seems reasonable for individual developers and smaller businesses. You could also consider a higher team or usage-based tier for companies processing larger volumes.
The biggest value proposition for me is simple: not just extracting data, but helping users know whether they can trust it. 🚀
The reconciliation layer feels like the real differentiator.
Are users more willing to pay for trusted output, or just faster extraction?
Honestly, so far trust is what people say they'd pay for, but speed is what gets them to try it in the first place. The pattern I keep seeing: someone shows up wanting a quick PDF-to-JSON, then the moment they hit a wrong number in a batch, the reconciliation becomes the thing they actually care about. So you probably need the fast extraction to get them in the door and the trust layer to keep the ones processing real volume. Still early though, so take that with a pinch of salt.
That distinction between what gets them to try and what makes the product valuable at volume is interesting. I’d like to dig into that a bit more privately — what’s the best email to reach you on?
Answers to your three questions, from the buyer's side:
Yes, "checks its own work" is the reason to pay — but only above a volume threshold. We process PDFs in our own product pipeline, and the failure mode you describe (a dropped row that looks perfectly fine) is exactly why a solo dev verifies by eye at 10 documents and stops being able to at 10,000. The buyer at volume is not choosing between your API and a free converter; they're choosing between your reconciliation flag and a month-end surprise. Lead with that for the API tier.
Landing page: lead with plain PDF-to-JSON. Reconciliation is your moat but it's a feature of one endpoint, and nobody searches for "self-reconciling converter". Category first, differentiator second — same reason a storefront leads with the product, not the QA process.
On pricing: $29/mo for a solo dev reads fair against the alternative (an hour of manual checking or one wrong number in a report). For teams, tie the tier to volume, not seats — the team of 3 processing 50k statements has the budget of a team of 10 processing 5k, and per-seat pricing makes you look cheap to your best buyer. A per-1k-statements overage above the base plan would match value to price better.
This is one of the most useful comments I've had, thank you. On (1), the volume-threshold framing is exactly right, and "your reconciliation flag vs a month-end surprise" is a sharper line than anything on my landing page right now. Below a handful of docs nobody needs it, so that's squarely an API-tier message. On (2), you've talked me out of leading with reconciliation. It is one endpoint, and nobody searches for a self-reconciling converter, so category first and differentiator second makes sense: plain PDF-to-JSON up top, reconciliation as the reason to stay once you're at volume. On (3), the per-seat point really lands. A small team can easily be my heaviest user, so tying the tier to statement volume with a per-1k overage fits the value far better than seats. I want to sit with the pricing before I change it, but that's the direction. Genuinely appreciate you taking the time to write this out.