Originally published at htpbe.tech. The version on htpbe.tech stays in sync with the latest detection algorithm — refer to it for the canonical text.
Somebody on your team has already written the prototype. An afternoon, pypdf or pdf-lib, count the cross-reference sections and flag anything above one. On the five sample files you handed it, it was right five times out of five.
That prototype is why this decision is hard. It is not fake – the signals are real and the code genuinely is that short. The trap is that the afternoon is not one percent of the project; it is the part with an obvious end, and everything after it is where the cost lives.
First, be specific about which project is actually on the table, because “PDF tamper detection” names three of wildly different size: a single narrow check on one document type from one issuer, a general edit signal on any PDF from anyone, or a verdict your workflow can safely automate against. The first is a weekend. The second is a quarter and never finishes. The third is a product.
This is the build-versus-buy argument written honestly, including where building is correct. The technical starting point for the build side is already published – detecting a tampered PDF in Python without the original walks the layers with working code, and PDF xref table forensics explains why the structural trail exists. This piece is about whether you should still be maintaining that code in twelve months.
When building is genuinely the right call
There are real situations where an in-house check wins, and if you are in one of them the rest of this is not for you.
You need one narrow check, not a verdict. Whether a signature on a document you issued yourself is still valid is a solved problem with mature libraries in every language and no tuning burden – you are verifying a cryptographic property, not judging a file of unknown origin. Do it in-house.
You control the document’s origin. If you generated the PDF, store a hash at generation and compare later – stronger evidence than any forensic inference, at almost no cost. Forensics is the fallback for when you only have the file.
The volume does not justify a vendor. A dozen documents a month, reviewed by someone who knows what to look for, does not need an integration.
Nothing may leave your network. Some environments cannot send documents to a third party, full stop. A hard constraint and a legitimate reason to build.
You are doing research, not intake. One-off investigations and incident response want a file you read yourself, not a verdict. Build the tooling.
Those five cost a vendor nothing to concede, because none of them was going to buy anyway. Here are three that do:
Document forensics is your own core competency. If you sell fraud detection, or your differentiation is the quality of your document review, the corpus and the tuning treadmill are not overhead – they are the asset you are paid for. Renting that from a competitor-adjacent vendor is a strategic mistake regardless of the arithmetic. Build it, staff it, and accept it is a permanent team.
You have to defend the method, not just the outcome. If an adverse decision must be justified to a regulator, an ombudsman or a court, “the vendor’s algorithm flagged it” is a weak position, and a check whose internal method is undisclosed is one you cannot fully explain on the stand. Named markers help, but if your process needs the reasoning reproducible end to end by your own expert, an implementation you can document line by line may be worth the maintenance cost. That is a real argument against buying, ours included, and no data-processing agreement fixes it.
At high enough volume the arithmetic flips. Per-check pricing scales with volume; in-house maintenance is roughly fixed once the corpus exists. There is a crossover – the costing section below is about finding yours.
Outside those cases – arbitrary documents from applicants, vendors, tenants or claimants, at a volume nobody wants to review by hand – the cost curve is the whole story.
The five costs nobody puts in the estimate
The estimate for building is almost always the estimate for the prototype. None of these numbers are ours to give you – they are line items you price for your own team, and most estimates omit them entirely.
1. Real PDFs do not behave like the specification
The format is old, enormous, and implemented by a long tail of software of varying quality. Files that render perfectly everywhere routinely deviate from what a strict reading of the specification predicts, because viewers are forgiving and generators exploit that. A parser written against the spec meets production traffic and starts throwing on entirely legitimate documents. That work is not hard; it is endless, and it arrives as individual production incidents rather than a project you can scope – each one a real user whose document you just rejected.
2. False-positive tuning is the actual product
This is the cost that sinks in-house builds, and people get it backwards. The naive rule – more than one cross-reference section means the file was written to again – is not wrong about the structure. The inference is sound, and a good detector does not explain it away.
The error is the next step: treating “a write happened” as “this document is suspect.” The distance between those two statements is the whole job.
You have to separate origins where the write is real evidence from origins where it is the document working as intended – a form the recipient legitimately filled in, a fill-and-sign overlay applied by the person asked to sign. Both produce exactly the write the naive rule flags, and getting it wrong means flagging honest applicants for doing what the document asked them to do.
Note what this is not claiming. A pipeline that genuinely rewrites the file after issue – an archival rebuild, a server-side optimizer – did modify the document. Where we can see that write, our policy is to report it rather than quietly excuse it, because the check reports the fact of an edit, not a guess at intent. Whether your workflow wants to hear about a benign re-save is a policy question, and answering it is part of the build estimate too.
What separates a signal from a verdict is context: which combinations of generator, structure and history are normal for a given kind of document. That does not come from the specification but from having looked at a large number of documents whose true status you already knew – which is what nobody budgets for. Building that corpus means collecting real files across many issuers and countries and adjudicating each, which is expert work, and it has to keep growing. This cost is not a number of engineering weeks; it is that there is no month in which false-positive work stops.
3. Generators and editors keep moving
Tool fingerprints are not a list you compile once. Editors ship versions that write different metadata, new converters appear, and long-standing generators change behaviour in a point release for reasons that have nothing to do with you. A rule that correctly separated an institutional generator from a consumer editor last year can quietly stop doing so.
You need not take our word for the cadence. Our changelog is the evidence, and the least flattering possible source, because it is a list of times we had to change something: 131 dated algorithm releases between February and August 2026, as of publication. Whoever owns your in-house version is signing up for that cadence, and for the on-call consequences when it slips.
4. The known-tools corpus is a second product
Separating an institutional generator from a consumer editor from an online converter needs a maintained database of software signatures; why that corpus, not the byte-reading, is the hard part is covered in the DIY walk-through. Price it as a standing research function attached to your engineering team, in perpetuity, for something that is not your product.
5. Coverage you will not build because you do not know it is missing
The prototype reads the well-known signals – dates, generator strings, save generations, signatures – well known because they are easiest to reach. In our own corpus, the hardest forgeries to catch are routinely the ones that leave nothing in those fields, across structural layers the prototype never looks at.
The problem is not that those layers are secret. It is that you do not know which you are missing, so their absence never shows up in your test results and your detector looks like it is working. For scale: our analysis currently runs 63 forensic checks across eight structural domains, as of publication. Treat that as surface area rather than completeness – we track our own known gaps internally, and the changelog is the public trace of working through them. Coverage is never finished, for us either. An in-house build need not match that number; it does need to know which fraction it covers, and most cannot answer the question.
What buying does not solve
An article arguing one side without this section is a sales pitch. Buying has real costs and limits, and they belong in the same comparison.
You are sending documents to a third party. A privacy and procurement question, and a legitimate blocker. Answerable – with a data-processing agreement, or a deployment inside your own network – but answerable, not absent.
You inherit someone else’s judgement. When a vendor returns modified, you are accepting their threshold for what counts as evidence. Named, stable markers make that inspectable rather than opaque – it is why our API returns marker IDs instead of a single risk score – but it is still their call.
You take on a critical-path dependency you do not control. If document checks gate intake, the vendor’s availability becomes your availability, their pricing becomes your unit economics at renewal, and a synchronous check puts someone else’s latency inside your response time. Building means you own an ongoing cost; buying means you own an ongoing risk. Which your organisation handles better depends on facts about your company that no vendor article can know, and we will not pretend otherwise.
Structural analysis has a hard ceiling, ours included. If a fraudster never edits a real document but builds a convincing fake from scratch, there is no post-creation modification to find – the file can be structurally pristine and entirely fabricated. Be precise about what happens then, because this is where the category gets oversold: a fabricated file never edited afterwards will most often come back intact, and intact does not mean the document is true. It means no disqualifying structural evidence was found – a statement about the file’s history, not about whether the numbers on the page are real.
inconclusive is a separate thing, driven by origin rather than suspicion: scans, print-to-PDF output, consumer software, online editors, filled-in forms. Those have no institutional baseline to check integrity against, so the honest answer is that structural analysis does not apply – not that the tool failed.
Both matter here. If you build, you have to build the discipline of saying “I cannot answer this one,” and resist the stronger temptation to read your own tool’s silence as a clean bill of health. A two-state detector that only reports modified or not quietly converts every unanswerable document into an approval – the worst possible default, and the one you get for free if nobody pushes back.
The decision, as questions
Run these in order. The first “no” usually settles it.
- Do you control the document’s origin? If yes, hash or sign at generation and skip forensics entirely.
- One narrow check, or an open verdict on arbitrary files? Narrow check, in-house. Open verdict, keep reading.
- Who reviews the output? If a person reviews every result anyway, you need a signal and can build one. If it feeds an automated decision, you need a verdict, and precision is not optional.
- Who owns it in month nine? Not who writes it – who is on call when a generator update starts flagging a bank’s genuine statements. “We’d figure that out” means you have not costed the project.
- Where does your labelled corpus come from? No answer means you cannot tune, and an untuned detector is a false-positive generator pointed at your own customers.
- Can documents leave your network? If not, check whether an in-network deployment exists before treating it as decisive.
- What does a miss cost, and what does a false accusation cost? Wrongly flagging honest applicants has a cost that appears in no fraud-loss model.
The answer most teams land on: build the routing, buy the verdict
The split that works is usually not build-or-buy at all. Your intake logic – which documents get checked, what happens on each verdict, how a flagged file is escalated and recorded – is specific to your business and nobody can sell it to you. Build that. The forensic layer underneath is a commodity with a maintenance treadmill attached; rent that, behind an interface narrow enough to replace. Your code branches on a verdict and a set of marker IDs, and nothing above that boundary knows how the verdict was produced:
if status == "modified":
escalate(case_id, markers) # post-creation edits found — human review
elif status == "inconclusive":
request_source_copy(case_id) # origin can't be structurally checked
else: # "intact" — no disqualifying structural evidence, not proof of truth
proceed(case_id)
The routing stays yours, and if you later bring the forensic layer in-house you replace one function rather than unpicking detection logic from across your pipeline. Buying is not a one-way door if you draw the boundary in the right place.
Costing the buy side honestly
The comparison that matters is not licence cost against zero. It is licence cost against your own loaded engineering cost for the same capability, including the maintenance items above, which never reach zero.
On our side: the HTPBE API is a two-call REST integration – submit a PDF URL, retrieve a verdict with named modification_markers – and the entry plan covers 30 checks a month at $15, with 350 at $149 and 1,500 at $499; current tiers are on the pricing page.
Then do the honest version of that comparison rather than the flattering one. Published pricing stops at 1,500 checks a month; above that it is a custom quote and the maths has to be redone with a real number, not an extrapolation. Because per-check cost scales with volume while in-house maintenance is roughly fixed once the corpus exists, there is a crossover where building wins on cost alone. Where it sits depends on your negotiated rate and your loaded engineering cost – work it out with your own two numbers, and do not let anyone, us included, wave it away. Well past that crossover, with forensics close to your core business, the answer here is legitimately “build.” Below it, the comparison is usually less close than teams expect, because the recurring items get left out of the build estimate and never out of the licence.
Either way, test the buy side first – the part most evaluations skip. A test key returns deterministic synthetic verdicts against fixed test URLs, so you can write and run the whole integration, including the inconclusive branch that most pipelines get wrong, before any real document is involved. Web signup includes five checks.
Then do the thing that actually settles this, whichever way you are leaning: take twenty documents whose status you already know, run them through everything you are considering – your own prototype included – and count the disagreements. Build-versus-buy arguments are cheap. A confusion matrix on your own traffic is not, and it will answer the question faster than any article, including this one.
