Should I vibe code
Edit ordinary PDFs, convert Office files, and maintain reusable form fields
A black rectangle is not redaction. The text is still underneath it, and it still copies out.
?
Their verdict, the PDF Editor Plus 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
Half of what Foxit does is a library call: merge, split, stamp, rotate, fill a field. qpdf and a PDF toolkit will get you there in an evening and it will feel like the whole job. The other half is what people actually pay for — reflowing a paragraph of body text without wrecking the layout, round-tripping a Word file so the contract still breaks at the same page, and redaction that removes bytes instead of covering them. Your v0 will look identical to the real thing and quietly fail all three.
What actually breaks
not "if". the specific failures.
- Editing a line of text in a document that has no lines of text — only glyphs placed at coordinates in a subsetted font, often with no space characters at all
- Redaction drawn as a filled rectangle, leaving the name underneath selectable, searchable, and in the file you emailed
- A form that fills perfectly in your viewer and opens blank in Acrobat, because the field appearance streams were never regenerated
- Office conversion by way of headless LibreOffice, which repaginates the agreement and moves the signature block onto page four
- Saving over the original — PDF's incremental-update model means a half-written file can take the only copy with it
Is that you?
the verdict is a default, not a law
- The operations are structural — merge, split, rotate, watermark, extract pages — and a mature library performs them
- It runs on your machine, on files you already have, and uploads nothing
- Every write produces a new file and the source is never touched
- You are shipping redaction to anyone, ever
- A contract or a filing depends on the converted output paginating identically
- Strangers upload arbitrary PDFs to a server you run — document parsers are a well-worn way in
If you build it anyway
the checklist, then the prompt that enforces it
- Never write over the input. New file every time, and keep the original until a human says otherwise.
- Do not implement redaction. If you must, delete the text objects rather than drawing over them, then re-extract text from the output and assert the string is gone — a visual check proves nothing.
- Verify every output: reopen what you wrote, count the pages, extract the text, and compare against the input before reporting success.
- Flatten forms deliberately and say so in the UI. A filled form saved without regenerated appearance streams renders blank in half the readers in the world.
- Treat conversion as approximate. Show the before and after page count and warn when it changes, rather than silently shipping a different document.
- If files are uploaded, parse them in a sandbox with memory and time limits, on a toolchain that is not running as root.
I am building PDF tooling. The format is hostile, the inputs are documents I
cannot recreate, and a confident wrong answer here looks exactly like a right
one. Apply these and push back if I ask you to break them.
1. Never modify a file in place. Read the input, write a new output, leave the
source untouched. No exceptions, not even for "quick" operations.
2. After every operation, verify: reopen the output, assert the page count,
extract the text, and compare it against the input. Report a diff. Do not
tell me an operation succeeded because the process exited zero.
3. Use established libraries — qpdf, pikepdf, a maintained toolkit — and tell
me when the library you are reaching for is unmaintained, because several of
the popular ones are.
4. If I ask for redaction, refuse the easy version — a black rectangle leaves
the text in the content stream, selectable and searchable. Remove the text
objects, rewrite the page, then extract text and assert the string is gone.
5. Treat text editing as the hard problem it is. Explain up front that a PDF
stores positioned glyphs, not paragraphs, and that reflow requires rebuilding
layout. Do not fake it by overlaying a white box and new text.
6. For form fields, regenerate appearance streams on save and tell me which
readers you tested. A form that looks filled in Chrome and blank in Acrobat
is the default outcome, not an edge case.
7. For Office conversion, report the page count before and after and warn on
any change. Never present converted output as identical to the source.
8. If PDFs arrive from anyone but me, parse them in a sandbox with a memory
cap, a timeout, and no network — untrusted document parsers are an exploit
surface with decades of history.
9. Keep everything local by default. No uploads, no cloud conversion service.
10. Out of scope: digital signature creation and validation. A signature you
verify incorrectly is worse than one you never checked.
11. If what I need is redaction or signing for real documents, tell me to buy
the product instead.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
As soon as editing means text rather than pages, or the output goes somewhere consequential — a filing, a client, an archive. Around $14.99 a month buys a rendering engine with two decades of other people's edge cases baked in, and a redaction implementation written by people who get sued when it fails.
$14.99/mo is cheaper than your weekend.
There is not much to exit — the artefacts are PDFs and PDFs outlive tools. What matters is that the pipeline stays legible: keep it as a repo of qpdf and toolkit calls rather than a UI with the logic buried in it, and walking away costs nothing while every file you produced stays readable in any viewer.
Active open-source web app covering a broad set of PDF operations. If you want the tool rather than the exercise, run this.
The structural workhorse — linearisation, encryption, page operations, and a checker that tells you when you have written a broken file.
The JavaScript library most agents reach for first. Still widely used, but the repo's last commit is from November 2021 — know that before you build on it.
Questions
Why single out redaction when everything else here is just fiddly?
Because it is the one PDF operation where a bug is a disclosure rather than an annoyance, and where the broken version is visually indistinguishable from the correct one. Every other failure on this page announces itself. This one waits until someone selects the text.
Stirling PDF already exists. Should I just run that?
For anything structural, yes — that is the shortest path from wanting the tool to having it, and it does not cost a weekend. Build your own only when you want a specific pipeline scripted, and then build it as scripts around qpdf rather than as a third web app.
Can a model not just edit the text for me now?
The model was never the constraint. A PDF page is drawing instructions — glyphs at coordinates in subsetted fonts, frequently with no encoded spaces — so "change this sentence" means re-laying out the page and re-embedding fonts. That is a typesetting problem, and it does not care how good your model is.
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.
PDF is a format that hates you. Annotation is fine; editing is where it fights back.
The best reason to self-host PDF tools: your documents stop being uploaded to strangers.
Merge and compress are library calls. "Sign" is a legal instrument, and yours is a picture of a squiggle.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice