Should I vibe code
Edit, convert, combine, and sign ordinary business PDFs locally
A bad PDF-to-Excel conversion doesn't crash. It hands you a spreadsheet that opens, sums, and is wrong.
?
Their verdict, the Nitro PDF Standard price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
The neighbours have taken the two obvious angles already — Foxit for redaction that draws a rectangle rather than removing bytes, DocHub for a signature with no audit trail behind it. Nitro's centre of gravity is elsewhere: conversion. PDF to Word, PDF to Excel, in batches, with OCR for the scans. That is the failure that never announces itself. A table extractor that merges two columns, an OCR pass that reads 8 as 3 in a total, a European invoice where 1.234,56 becomes one thousand two hundred and thirty-four — none of these throw an exception. They produce a spreadsheet that opens, sums, and is wrong, and then you forward it. The local, read-only half of this is a good project and qpdf and OCRmyPDF have already done most of it. Just never let it write over the file it read, and never trust a number it produced without looking at the page it came from.
What actually breaks
not "if". the specific failures.
- Table extraction, which infers cell boundaries from whitespace and gets merged cells wrong without ever saying so
- OCR on a scan, where a per-character confidence score existed right up until your pipeline threw it away
- Locale, because a European invoice writes 1.234,56 and a naive parser reads one thousand two hundred and thirty-four
- Batch mode writing output over input, which is how a folder of source documents becomes a folder of your first attempt
- Round-tripping to Word, where the layout survives and the numbering, styles and cross-references quietly do not
- Encrypted and permission-flagged PDFs, which your library will either refuse outright or silently strip the restrictions from
- Malformed PDFs off the internet, which are a well-worn path into parsers and into whatever you shelled out to for rendering
- Subset fonts with no embedded encoding, where text extraction returns glyph ids and your output is confident nonsense
Is that you?
the verdict is a default, not a law
- It runs locally over documents you already hold and writes into a new directory every single time
- The operations are the structural ones: merge, split, rotate, compress, extract and reorder pages
- Any extracted number is displayed next to the page region it came from, so checking it takes a glance
- You are orchestrating qpdf, OCRmyPDF and a PDF toolkit rather than parsing the format yourself
- It converts financial or contractual documents and the output leaves your hands unchecked
- It processes PDFs from strangers on a machine that has anything else on it
- Batch operations can overwrite the originals, or write into the directory they read from
- You need faithful PDF-to-Office round-tripping, because that is precisely the thing being sold
If you build it anyway
the checklist, then the prompt that enforces it
- Never write into the input directory. Output goes to a new tree, originals stay read-only, and every batch produces a manifest of what it did.
- Keep OCR confidence and render anything below your threshold as visibly uncertain. Discarding confidence is what turns a legible error into an invisible one.
- Parse numbers with an explicit locale, and refuse to guess. A silently mis-parsed decimal separator is the single most expensive bug in this category.
- Show provenance for every extracted value: page, bounding box, and the source glyphs. If a figure cannot be traced back to a region of the page, do not emit it.
- Wrap the battle-tested tools — qpdf, pdfium, OCRmyPDF, Tesseract — rather than writing a PDF parser. The format has thirty years of pathological files in it.
- Sandbox anything that touches a PDF you did not create: separate process, no network, restricted filesystem, hard timeout. Document parsers are a classic memory-safety surface.
- Verify structurally after every write — reopen the output, count pages, extract text, compare against the input — and fail loudly rather than producing a file that merely opens.
I am building a local PDF tool: merge, split, convert to Word and Excel, OCR scans, batch process folders. Treat silent conversion errors as the main hazard and refuse the shortcuts that hide them.
1. Before any conversion feature, fix the file-handling rule: never write into the input
directory, never overwrite an original, always emit to a new tree with a manifest.
2. Build the structural operations first — merge, split, rotate, extract pages — by wrapping
qpdf. Do not write a PDF parser; say why the format does not reward it.
3. After every write, reopen the output and verify: page count, extractable text, embedded
fonts. Fail loudly rather than producing a file that opens and is wrong.
4. For OCR, use OCRmyPDF or Tesseract and keep per-word confidence. Render anything under
threshold as visibly uncertain and never strip confidence from the pipeline.
5. Parse every number with an explicit locale I have chosen. Refuse to infer whether a comma
is a decimal or a thousands separator, and tell me this is the most expensive bug here.
6. Every extracted value carries provenance — page number and bounding box — and the UI can
show me the region it came from. No untraceable figures.
7. For table extraction, output a confidence signal per table and flag merged or spanning
cells explicitly rather than flattening them into a plausible grid.
8. Process untrusted PDFs in a separate process with no network access, a restricted
filesystem and a hard timeout. Document parsers are a memory-safety surface.
9. Detect encrypted and permission-restricted PDFs and stop. Never silently strip protection
from a document; tell me what was found and let me decide.
10. Batch runs are dry-run first: produce the manifest of intended operations, and take that
manifest as input to the real run.
11. Out of scope unless I ask again: signature requests, cloud storage, and anything that
sends a document somewhere. Signing is a separate product with an evidence problem — see the DocHub entry.
12. Finish by telling me that faithful PDF-to-Office round-tripping is the thing being sold
for $15 a seat, and that my version will be worse at exactly that.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
The conversions matter. $15 a seat a month buys the one thing this category actually charges for: a PDF-to-Office engine that keeps a table a table, an OCR stack tuned on a lot of bad scans, and a vendor who has already met the malformed files that will crash yours. Stirling PDF self-hosted covers the whole structural half for nothing and is the part genuinely worth owning.
$15/mo is cheaper than your weekend.
There is barely anything to exit, and keep it that way: outputs are ordinary PDFs, DOCX and XLSX in a dated folder tree, never a proprietary project file. Keep the manifest each batch produced — inputs, operations, outputs, tool versions — because that is what lets you re-derive a conversion later or work out which run produced the wrong number. Originals never move.
Active open-source web application for a broad set of PDF operations.
Adds a searchable OCR text layer to scanned PDFs without rewriting the original page images.
Content-preserving PDF transformation library and CLI; the safe engine under merge, split, linearise and repair.
Questions
Foxit and PDF Expert are already DEMO ONLY. What is left to say?
Those two are about editing — reflowing body text, and redaction that removes bytes instead of covering them. Nitro's weight sits on conversion and OCR, which fail differently: not with a mangled layout you can see, but with a spreadsheet that looks fine and contains a number nobody typed. The guardrails here are consequently about provenance and confidence rather than about what a black rectangle does.
Is OCR not basically solved now?
Recognition is good and getting better. What is not solved is knowing when it was wrong, and that is a pipeline decision rather than a model one. Every serious OCR engine emits per-word confidence; the fifteen-line version you generate on a Saturday takes the string and drops the score. Keep the confidence, show low-confidence spans differently, and a scanned invoice becomes checkable rather than merely plausible.
Why does a local desktop tool score anything at all on security surface?
Because PDFs are programs in the loose sense — embedded fonts, JavaScript, streams, filters — and the parsers that read them have a long history of memory-safety bugs. If your tool opens documents that arrived by email and shells out to a renderer, that renderer is now attacker-reachable on a machine with your files on it. A separate process, no network and a hard timeout costs an hour and removes the whole class.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
A black rectangle is not redaction. The text is still underneath it, and it still copies out.
PDF is a format that hates you. Annotation is fine; editing is where it fights back.
An e-signature is not a picture of a squiggle. It's the audit trail you'll be asked for two years later.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice