DEV Community: Iurii Rogulia

PDF Integrity Report: February 2026

Iurii Rogulia — Sat, 23 May 2026 10:00:26 +0000

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.

Every month we look at aggregate, anonymized data from checks processed through the HTPBE? web interface and publish what we find. No file contents, no personally identifiable information — only the structural and metadata signals our algorithm uses to detect modifications.

February 2026: 418 PDFs analyzed through the website, 28 calendar days, steady daily volume.

The Top Line

Metric	Value
Total PDFs analyzed	418
Flagged as modified	169 (40.4%)
Clean	249 (59.6%)
Total data volume	210.3 MB
Total pages analyzed	1,902

Two in five PDFs submitted through the website in February showed signs of post-creation modification. That is a higher rate than cross-industry averages suggest — but it reflects the selection bias of fraud detection workflows: people check documents when they have a reason to be concerned.

Modification Confidence Distribution

Confidence level	Count	Share
None (no modification detected)	211	50.5%
High (strong structural evidence)	24	5.7%
100% (cryptographic proof or definitive markers)	145	34.7%
cannot determine (consumer software origin)	38	9.1%

More than a third of all uploaded PDFs carried 100% modification confidence — meaning the evidence was unambiguous, not probabilistic. These documents carry stacked forensic signals — a date mismatch, incremental update artifacts, and tool-signature inconsistencies.

Files with high-confidence (but not 100%) findings deserve attention: 24 files, 5.7% of the total. These documents show strong structural evidence — suspicious fields, questionable timestamps — but no single finding rises to the level of cryptographic proof. In a compliance workflow, these warrant manual review.

How Modifications Are Detected

Among the 169 flagged files, the algorithm identified the following signals:

Detection signal(s)	Files	% of modified
Modification date differs (only)	58	34.3%
Incremental updates + modification date differs	31	18.3%
Incremental updates (only)	15	8.9%
Incremental updates + suspicious update pattern	15	8.9%
No explicit signal (rule-based verdict)	15	8.9%
All three: incremental + suspicious + date	8	4.7%
Invalid date sequence + anomalies + date differs	6	3.6%
Tool signature mismatch combinations	7	4.1%

The single most common detection signal — appearing in 62% of flagged files — is a discrepancy between the embedded creation and modification timestamps. A document edited in an external tool will often have its modification date updated while the original creation date remains as set by the authoring software. This divergence, when combined with other signals, becomes a strong forensic indicator.

Incremental updates were detected in 97 files (23.2% of all February checks). This is the PDF mechanism that allows appending content — annotations, form data, revised pages — without rewriting the file. Among those 97 files, the average update chain length was 2.6 revisions. Crucially, 59 of those 97 files (60.8%) were also classified as modified. The remaining 40% showed incremental updates consistent with legitimate workflows: annotations, digital signatures, or form completion.

Critical modification markers across all flagged files:

Different creation and modification dates — 113 files
Multiple cross-reference tables (incremental updates) — 40 files
Known PDF editing tool detected — 15 files

The Software Ecosystem

PDF metadata reveals which software created and last touched a document. February showed a clearly Microsoft-centric picture, with significant freelance-platform presence.

Top producers (the application that last wrote the file):

Producer	Files	Share
Microsoft: Print To PDF	24	5.7%
PDFium	20	4.8%
mPDF 8.2.5	18	4.3%
Upwork	16	3.8%
Microsoft® Word for Microsoft 365	12	2.9%
iLovePDF	11	2.6%
Style Report	11	2.6%
OpenPDF 1.3.26	11	2.6%
PDFsharp 1.50	10	2.4%

Top creators (the original authoring application):

Creator	Files	Share
PDFium	21	5.0%
Upwork	16	3.8%
Microsoft® Word 2016	14	3.3%
Microsoft® Word for Microsoft 365	13	3.1%
Style Report	11	2.6%
PDFsharp 1.50	10	2.4%
PScript5.dll Version 5.2.2	9	2.2%
Chromium	9	2.2%
Microsoft Word	8	1.9%
Microsoft® Word 2019	6	1.4%

Several patterns worth noting.

Microsoft Word fragments into multiple entries. Word 2016, Word 2019, Word for Microsoft 365, and the generic “Microsoft Word” string together account for 41 files — the single largest authoring platform if consolidated. Organizations upgrading their Office installations leave version-heterogeneous document archives, and all of those versions end up in fraud detection queues.

iLovePDF in the producer field signals documents that were processed through an online PDF manipulation service after their original creation. When a file lists iLovePDF as producer but names Microsoft Word or Chromium as creator, the document went through an intermediate editing step that the creator field does not acknowledge. Eleven files carried this pattern in February.

Upwork appears in both creator and producer (16 files each). The Upwork platform generates its own PDFs — contracts, payment statements, work history reports — and they are being submitted for authenticity analysis by counterparties before acting on them. This reflects a real-world use case: recipients checking freelance platform documents before releasing funds or signing agreements.

mPDF 8.2.5 (18 files as producer) is a PHP PDF library used by web applications to generate invoices, receipts, and reports programmatically. These are application-generated documents, not user-authored files — which makes any structural inconsistency more notable, since they should be templated and uniform.

PDFium appearing in both creator and producer (20 and 21 files respectively) reflects Chrome-based PDF generation — printouts from web applications, saved browser pages, Google Docs exports.

PDF Version Landscape

PDF Version	Files	Share
1.7	154	36.8%
1.4	113	27.0%
1.5	66	15.8%
1.6	35	8.4%
1.3	36	8.6%
2.0	3	0.7%
1.2	3	0.7%
Invalid/missing	7	1.7%

PDF 1.7 leads at 36.8%, with 1.4 a strong second at 27%. Together they account for nearly two thirds of the sample. PDF 2.0 — the ISO 32000-2 standard from 2017 — appears in just 3 files (0.7%), reflecting how slowly the ecosystem adopts new specifications.

Seven files had an invalid or unparseable version string. A well-formed PDF should always declare its version in the file header; losing this field is a sign of either corruption or aggressive editing that stripped the header.

Digital Signatures: Present but Not Protective

11 PDFs carried embedded digital signatures (2.6% of the total). Of those, 3 had been modified after the signature was applied — a 27.3% post-signature modification rate among signed documents.

The mechanism most commonly exploited here is incremental updates. The PDF specification permits content to be appended after a signature is applied, provided the additions are limited to explicitly permitted operations. Some editors exploit the ambiguity of what constitutes a “permitted” change to introduce substantive content modifications — revised figures, changed dates, altered party names — while preserving a signature that remains cryptographically valid within its original scope.

The result: a document that displays a valid signature indicator in a viewer, but whose content has changed since signing. The signature covers what it covered when it was applied; it does not cover what was added afterward.

In practice, most organizations treat the presence of a signature field as sufficient fraud detection. Active signature validation — which would surface these post-signature modifications — is rarely performed outside of legal and financial workflows with formal fraud detection requirements.

Document Profile

The average PDF checked through the website in February:

Average size: 0.50 MB
Largest file: 9.70 MB
Average page count: 4 pages
Total pages analyzed: 1,902

The half-megabyte average is consistent with the document types typically submitted for fraud detection: invoices, contracts, bank statements, certificates. Short documents with specific numerical or legal content — where a changed figure or date has real financial or legal consequence.

Metadata completeness averaged 76 out of 100. The score measures how many of the eight standard PDF metadata fields (title, author, creator, producer, creation date, modification date, subject, keywords) are populated. Missing creation dates affected 53 files (12.7%) — removing one of the cleaner forensic signals and increasing reliance on structural analysis.

Daily Volume

Usage was steady throughout February, without dramatic spikes:

Feb 06: 28    Feb 14: 11    Feb 22:  1
Feb 07: 10    Feb 15: 20    Feb 23: 24
Feb 08:  1    Feb 16: 25    Feb 24: 12
Feb 09: 11    Feb 17: 28    Feb 25: 47
Feb 10: 25    Feb 18: 11    Feb 26: 20
Feb 11: 16    Feb 19: 20    Feb 27: 24
Feb 12: 32    Feb 20: 14    Feb 28:  4
Feb 13: 20    Feb 21: 14

The peak day was February 25 with 47 checks — roughly 1.7× the monthly daily average of 27.5. No batch processing, no anomalous spikes. The distribution reflects organic usage: higher on weekdays, quieter on weekends, with the first week of the month running slightly lighter than the rest.

Other Signals

JavaScript in PDFs: zero across all 418 files. No embedded JavaScript was detected in February. This is consistent with the document types: invoices, contracts, and certificates do not use interactive scripting.

Embedded files: 4 (less than 1%). PDFs can contain binary attachments. Four documents carried embedded content. Not unusual, but worth flagging in any workflow where file attachments introduce compliance risk.

Suspicious tool patterns: 50 files (12.0%). This flag indicates that the creator–producer metadata combination is internally inconsistent in ways that suggest an unacknowledged intermediate processing step. The file claims a creation toolchain that does not match its structural fingerprint.

Summary

February 2026 by the numbers:

40.4% of submitted PDFs showed modification signals — significantly above the commonly cited 25–30% industry baseline, consistent with the self-selection of fraud detection workflows
Modification date discrepancy is the leading forensic indicator, present in 62% of flagged files
Microsoft Office ecosystem (Word across multiple versions, Print to PDF) is the primary authoring environment in this sample
iLovePDF and online editors leave traceable producer-field evidence in files that subsequently pass through fraud detection
Upwork documents are a recurring fraud detection target — freelance contracts and payment records being checked by counterparties
Digital signatures do not guarantee post-signature integrity — 27% of signed files in this sample were modified after signing
PDF 2.0 adoption remains below 1% despite being available for nearly a decade

The 40.4% modification rate is the most important number from February. It means that when someone uploads a PDF to check its authenticity, there is more than a one-in-three chance the document will come back flagged. That is not a marginal outcome — it is why fraud detection workflows exist.

Data covers all checks submitted through the HTPBE? web interface in February 2026 (UTC). File contents are not stored or analyzed; only structural metadata signals are retained. All figures are aggregate and anonymized.

EU VAT Rate Types Explained: Standard, Reduced, Super-Reduced, Parking, and Territorial Rates

Iurii Rogulia — Sat, 23 May 2026 09:00:27 +0000

Originally published at vatnode.dev. The version on vatnode.dev is the canonical source — refer to it for the latest content.

EU VAT is not a single number per country. Each member state can have up to four different rate types, and several countries have autonomous regions or overseas territories where completely different rules apply — or where VAT does not exist at all. This guide covers every rate type, when it applies, why it exists, and which territories you need to watch out for.

The four EU VAT rate types

The EU VAT Directive (2006/112/EC) defines four possible rate categories. No country uses all four — most use two or three. Here is what each means, when it applies, and why it exists.

Standard rate

Universal · 17%–27%

The default rate applied to all goods and services that do not fall into a special category. Every EU member state must have a standard rate of at least 15% (in practice the minimum today is 17% in Luxembourg, the maximum 27% in Hungary). If you are unsure which rate applies, use the standard rate.

Typical examples:

Software licences
Consulting services
Electronics
Clothing
Most B2B services

Legal basis: Art. 96–97, VAT Directive 2006/112/EC

Reduced rate

Common · 5%–18%

A lower rate — at least 5% — that EU countries may apply to a defined list of goods and services set out in Annex III of the VAT Directive. Countries can have up to two different reduced rates. The list covers categories considered socially or economically important: food, medicines, books, passenger transport, hotel accommodation, cultural events, and more.

Typical examples:

Food and non-alcoholic drinks
Books, newspapers, e-books
Medicines and medical devices
Passenger transport
Hotel accommodation
Renovation of residential property
Cultural and sports services

Legal basis: Art. 98–99 and Annex III, VAT Directive 2006/112/EC

Super-reduced rate

Limited countries · Below 5%

An exceptionally low rate, below 5%, that only a handful of EU states are permitted to keep as a historical exception. These rates predate the EU's 1993 VAT harmonisation and are grandfathered in — new member states cannot introduce them. They typically apply to the most essential goods: certain foods, newspapers, medicines, or tickets to cultural events.

Typical examples:

France: 2.1% — certain medicines reimbursed by social security; press publications
Spain: 4% — basic foodstuffs (bread, milk, cheese, eggs); books and newspapers; medicines
Italy: 4% — basic foodstuffs; books; certain agricultural products
Cyprus: 3% — certain foodstuffs; books and newspapers
Luxembourg: 3% — foodstuffs; certain printed matter; children's shoes

Legal basis: Art. 110 (standstill clause), VAT Directive 2006/112/EC

Parking rate

Transitional · ≥ 12%

A parking rate is a transitional measure introduced when the EU harmonised VAT in 1993. Before harmonisation, many countries applied reduced rates to goods and services that the Sixth VAT Directive (77/388/EEC) did not include in Annex III — meaning those items would have needed to jump straight to the full standard rate. Rather than forcing an abrupt increase, the EU allowed states to "park" those items at an intermediate rate of at least 12% until they could be phased out or reassigned. Decades later, several countries still use it.

Typical examples:

Belgium 12%: certain fuels for heating and agricultural use; cut flowers; restaurant services
Greece 13%: selected agricultural goods; some printed publications
Luxembourg 14%: wine; certain print materials; firewood
Malta 12%: certain printed matter; certain confectionery items
Portugal 13%: wine; certain animal feed; some agricultural inputs

Legal basis: Art. 103 (parking rate) and Art. 109–110, VAT Directive 2006/112/EC

The parking rate in depth

Of the four rate types, the parking rate is the least understood and the most likely to confuse developers encountering it for the first time. Here is the full picture.

Where does it come from?

When the EU adopted the Sixth VAT Directive in 1977 and then completed the single market in 1993, it defined a fixed list (Annex III) of goods and services that could qualify for a reduced rate. Many member states had existing reduced rates on items not on that list — cutting flowers, wine, certain fuels, printed advertising material, among others.

Rather than forcing an immediate jump to the full standard rate (which could have been politically and commercially disruptive), the directive allowed states to park those items at an intermediate rate of at least 12% while they gradually aligned their rules. The word "parking" is literal — the rate is parked there, in a transitional state, until the country moves it up to the standard rate or the EU adds the item to Annex III.

Why does it still exist in 2026?

The transition was never completed. Five EU countries still use the parking rate: Belgium, Greece, Luxembourg, Malta, and Portugal. Each has found that the political will to remove the rate entirely is weaker than the pressure from the industries benefiting from it. The EU has not imposed a deadline for abolition.

From a legal standpoint, the parking rate is allowed as a derogation under Article 103 of the VAT Directive. The minimum is 12%; there is no maximum other than the standard rate. Luxembourg uses 14%, Portugal and Greece 13%, Belgium and Malta 12%.

How to handle it as a developer

Most SaaS and e-commerce products never need to worry about parking rates — they apply to physical goods in very specific categories. But if you are building a general-purpose VAT calculation engine or a tax classification tool, you need to be aware that:

A country's "reduced rates" array in the vatnode API or eu-vat-rates-data package does NOT include the parking rate — it has its own parkingRate field.
Parking rates are listed separately in the EC TEDB database under the rate type REDUCED/PARKING_RATE.
The parking rate is never the rate that applies by default to unclassified goods — that is always the standard rate.
If you display a country's rates to users, show the parking rate only if you support the specific goods categories it covers.

Territorial exceptions — where rates differ

Several EU member states have overseas territories, autonomous regions, or special enclaves where the normal VAT rules do not apply. There are two distinct situations:

Outside the EU VAT area — Transactions with these territories are treated as imports or exports. EU VAT does not apply — the territory has its own local tax system (or none at all).

Inside the EU VAT area — lower rates — The territory is in the EU VAT area and follows standard VAT rules (invoicing, registration, recovery), but the rates themselves are lower than the mainland. Article 105 of the VAT Directive permits this for ultra-peripheral regions.

Spain

Canary Islands

Outside EU VAT area

Tax system: IGIC — Impuesto General Indirecto Canario

Standard: 7%
Reduced: 3%
Super-reduced: 0%
Increased: 9.5%, 15%

The Canary Islands are geographically located off the African coast and are excluded from the EU VAT area under Annex I of the VAT Directive. Goods shipped from mainland Spain or from another EU country to the Canary Islands are treated as exports — no EU VAT is charged, but IGIC applies on arrival. The rate is dramatically lower than the mainland standard of 21%, making the islands a popular destination for duty-free shopping.

EU VAT does not apply — do not charge or show VAT on invoices for this territory.

Ceuta & Melilla

Outside EU VAT area

Tax system: IPSI — Impuesto sobre la Producción, los Servicios y la Importación

Range: 0.5%–10%

These Spanish enclaves on the northern coast of Morocco are neither in the EU customs territory nor the EU VAT area. They levy IPSI at very low rates depending on the type of good or service. Transactions with Ceuta and Melilla are treated as imports/exports for VAT purposes.

EU VAT does not apply — do not charge or show VAT on invoices for this territory.

Portugal

Azores

Inside EU VAT area — lower rates

Tax system: Portuguese VAT (IVA) at reduced regional rates

Standard: 16%
Intermediate: 9%
Reduced: 4%

The Azores are an autonomous region within the EU VAT area. Article 105 of the VAT Directive allows the Portuguese legislature to apply lower VAT rates to autonomous ultra-peripheral regions. The Azores standard rate of 16% compares to 23% on the mainland — a reduction of 7 percentage points. The intermediate rate of 9% corresponds to the mainland's 13%, and the reduced rate of 4% to the mainland's 6%. Businesses operating in or shipping to the Azores must apply Azorean rates.

EU VAT invoicing rules apply — include VAT number and rate on invoices.

Madeira

Inside EU VAT area — lower rates

Tax system: Portuguese VAT (IVA) at reduced regional rates

Standard: 22%
Intermediate: 12%
Reduced: 5%

Madeira is another Portuguese ultra-peripheral region with the same legal basis as the Azores but with slightly different rates — standard 22% vs 16% in the Azores. The difference reflects regional policy choices. Like the Azores, Madeira is fully in the EU VAT area, so regular VAT rules on invoicing, registration, and input tax recovery apply.

EU VAT invoicing rules apply — include VAT number and rate on invoices.

France

Guadeloupe, Martinique, Réunion

Inside EU VAT area — lower rates

Tax system: French VAT (TVA) at DOM rates

Standard: 8.5%
Reduced: 2.1%
Intermediate: 3.74%

These French overseas departments (DOM — Départements d'Outre-Mer) are part of the EU VAT area as ultra-peripheral regions. Article 105 of the VAT Directive permits France to apply lower rates. The standard rate of 8.5% is less than half of the French mainland rate of 20%. Supplies from mainland France to DOM territories are treated as intra-EU supplies; the DOM rate applies at the destination.

EU VAT invoicing rules apply — include VAT number and rate on invoices.

French Guiana & Mayotte

Outside EU VAT area

Tax system: No VAT

VAT: Not applicable

French Guiana (on the South American mainland) and Mayotte (an island in the Indian Ocean) are explicitly excluded from the EU VAT area under Annex I of the VAT Directive. No VAT is levied on goods or services in these territories. Transactions are treated as exports from the EU perspective.

EU VAT does not apply — do not charge or show VAT on invoices for this territory.

Greece

Selected Aegean islands

Inside EU VAT area — 30% reduction

Tax system: Greek VAT (ΦΠΑ) at island rates

Standard: 17% (vs 24%)
Reduced: 9% (vs 13%)
Super-reduced: 3% (vs 4%)
Parking: 9% (vs 13%)

Certain islands in the North Aegean and Dodecanese groups — including Lesvos, Chios, Samos, Ikaria, Rhodes, and Kos — benefit from a 30% reduction on all Greek VAT rates. The measure was originally introduced to support the economies of islands close to the Turkish border. It has been renewed repeatedly and remains in force. The reduced rates apply to supplies made within the island; goods shipped from the mainland are generally subject to mainland rates.

EU VAT invoicing rules apply — include VAT number and rate on invoices.

Germany

Büsingen am Hochrhein & Helgoland

Outside EU VAT area

Tax system: No German VAT

VAT: Not applicable

Büsingen is a German exclave surrounded entirely by Switzerland and is excluded from both the EU customs territory and the EU VAT area. Swiss VAT rules apply in practice. Helgoland is a small island in the North Sea that was kept outside the EU VAT area for historical reasons. Supplies to both territories are treated as exports.

EU VAT does not apply — do not charge or show VAT on invoices for this territory.

Italy

Livigno & Campione d'Italia

Outside EU VAT area

Tax system: No VAT

VAT: Not applicable

Livigno is a high-altitude ski resort near the Swiss border that has historically enjoyed duty-free status. Campione d'Italia is an Italian exclave inside Switzerland. Both are excluded from the EU VAT area. Goods supplied to Livigno or Campione d'Italia are zero-rated as exports from an Italian VAT perspective.

EU VAT does not apply — do not charge or show VAT on invoices for this territory.

Finland

Åland Islands

Special fiscal territory

Tax system: Finnish VAT — but special tax boundary with mainland

Standard: 25.5% (same as mainland)
Reduced: 10%, 13.5% (same as mainland)

The Åland Islands are in the EU VAT area and apply standard Finnish VAT rates. However, because of their special political autonomy status (a demilitarised, self-governing region under the 1921 League of Nations decision), the EU treats the Finland–Åland border as a fiscal boundary. This means that travel between Åland and mainland Finland counts as an "import/export" for VAT purposes, which is why ferries between Helsinki and Stockholm stopping at Mariehamn can sell duty-free goods. The VAT rates themselves are identical to the Finnish mainland.

EU VAT invoicing rules apply — include VAT number and rate on invoices.

Developer notes: what this means for your API calls

When validating a VAT number or determining rates for a transaction, the country code alone is not always sufficient. Here is what to keep in mind:

Canary Islands, Ceuta, Melilla, Büsingen, Helgoland, Livigno, French Guiana, Mayotte

These territories have no EU VAT registration. A business operating exclusively in these areas will not have an EU VAT number (or will have one that reflects the parent country but should not be charged EU VAT for local supplies). The standard country code for the parent state is returned by VIES, but billing software must check the delivery address before applying rates.

Portugal: PT-AC (Azores) and PT-MA (Madeira)

These are valid EU VAT registrations. The Portuguese NIF is the same format across mainland and islands. If your system collects a delivery address, apply Azorean or Madeiran rates when the postal code falls within those regions. The vatnode /rates endpoint returns mainland rates for PT — you need to handle regional logic in your application.

Greece: island rate zone

There is no separate country code or VAT prefix for Greek island rates. The determination is based on the delivery address (postal code / island name). The standard GR country code is used for all Greek VAT numbers regardless of where the business is located.

Parking rate classification

The vatnode API and eu-vat-rates-data package return parkingRate as a dedicated field, separate from reducedRates. Do not merge them. When classifying goods, parking rates apply only to historically grandfathered product categories — they are never a default fallback.

The vatnode rates endpoint returns all four rate types in a single call. You can also browse current rates interactively in the EU VAT rates tool.

curl https://api.vatnode.dev/v1/rates/BE

{
  "countryCode": "BE",
  "countryName": "Belgium",
  "vatName": "Belasting over de toegevoegde waarde",
  "vatAbbr": "BTW",
  "currency": "EUR",
  "standardRate": 21,
  "reducedRates": [6, 12],   // note: parkingRate is separate
  "superReducedRate": null,
  "parkingRate": 12,          // Belgium's parking rate
  "countryVatUpdatedAt": "2026-04-02"
}

FAQ

What is a parking VAT rate?

The parking rate is a transitional VAT rate that some EU member states kept after the 1993 VAT harmonisation. It applies to goods and services that were at a reduced rate before the EU's Sixth VAT Directive but no longer qualify for a reduced rate under harmonised rules. The parking rate must be at least 12% and is currently used by Belgium, Greece, Luxembourg, Malta, and Portugal.

Is VAT applied in the Canary Islands?

No. The Canary Islands are part of the EU customs territory but are excluded from the EU VAT area. They use their own indirect tax called IGIC (Impuesto General Indirecto Canario) with a standard rate of 7%, which is much lower than the Spanish mainland VAT of 21%.

Do the Azores and Madeira have different VAT rates from mainland Portugal?

Yes. The Azores and Madeira are autonomous regions within the EU VAT area, but EU law permits them to apply lower rates. The Azores have a standard rate of 16% (vs 23% on the mainland) and Madeira 22%. Reduced rates are also lower in both regions.

Which Greek islands have reduced VAT rates?

Certain Aegean islands close to Turkey — including Lesvos, Chios, Samos, and the Dodecanese — benefit from a 30% reduction on all Greek VAT rates. This gives them a standard rate of 17% instead of 24%, and proportionally lower reduced and parking rates.

Next.js SaaS Checklist: Launch Production-Ready in 8 Weeks

Iurii Rogulia — Sat, 23 May 2026 07:00:25 +0000

I've built several SaaS products. Each time I run through the same checklist. Not because I'm following a template — but because I've paid for skipping items with production incidents, angry customers, and weekends spent fixing what should have been done at the start.

vatnode.dev — EU VAT validation SaaS, running in production with 95% Redis cache hit rate. htpbe.tech — PDF forensics SaaS, 5-layer analysis in under 9 seconds. pi-pi.ee — B2B e-commerce across 32 EU markets. All of them went from zero to production in 6–8 weeks. Here's exactly what that takes.

The Stack I Start With

Before the checklist, the decision I never revisit: the default stack.

Next.js 15 (App Router) for the web application — Server Components, Server Actions, API routes in one framework
Hono 4 when I need a dedicated API server (separate deployment, higher performance needs, BullMQ workers)
PostgreSQL — the only database I trust for production SaaS
Drizzle ORM — type-safe, no magic, migrations I understand
Better Auth — auth library that handles sessions, OAuth, magic links properly
Stripe — payments, full stop
Resend — transactional email
Redis (Upstash or self-hosted) — rate limiting, queues, caching
BullMQ — background job queue on top of Redis
Vercel — hosting, with caveats I'll get to
Sentry — error tracking

Every project deviation from this stack has cost me time. I now treat any deviation as a decision that requires justification, not exploration.

Auth Checklist

slug="mvp-development"
text="I build the full SaaS foundation — auth, billing, database, background jobs, monitoring — so you can focus on the product, not the plumbing."
/>

Auth is where most SaaS projects spend too much time if they roll their own, and too little time if they just copy a tutorial.

[ ] Email + password with bcrypt — minimum 12 rounds, store only the hash
[ ] Magic links — better UX for B2B tools where users don't want another password
[ ] OAuth: Google and GitHub — covers 80% of developer and startup users
[ ] Session management — use database sessions, not JWT-only (you need the ability to revoke)
[ ] Rate limiting on auth endpoints — login, register, password reset, magic link send
[ ] Email verification — required before first login, not optional
[ ] Password reset flow — expiring tokens, single-use
[ ] Account deletion — GDPR requirement, not an afterthought

I use Better Auth on all current projects. It handles sessions, OAuth providers, email verification, and password reset in one library. NextAuth.js is fine, but Better Auth has better TypeScript ergonomics and the plugin model is cleaner.

Here's the core Better Auth setup I start every project with:

// lib/auth.ts
import { betterAuth } from "better-auth";
import { drizzleAdapter } from "better-auth/adapters/drizzle";
import { db } from "@/packages/db";
import { magicLink } from "better-auth/plugins";

export const auth = betterAuth({
  database: drizzleAdapter(db, {
    provider: "pg",
  }),
  emailAndPassword: {
    enabled: true,
    requireEmailVerification: true,
  },
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    },
    github: {
      clientId: process.env.GITHUB_CLIENT_ID!,
      clientSecret: process.env.GITHUB_CLIENT_SECRET!,
    },
  },
  plugins: [
    magicLink({
      sendMagicLink: async ({ email, url }) => {
        // Resend integration — see Email section below
        await sendMagicLinkEmail({ email, url });
      },
    }),
  ],
  rateLimit: {
    enabled: true,
    window: 60, // 60 second window
    max: 10, // 10 requests per window per IP
  },
});

export type Session = typeof auth.$Infer.Session;

Better Auth generates the database schema automatically. Run npx better-auth generate and it outputs the Drizzle migration.

When to choose NextAuth.js instead: if you're on an older Next.js Pages Router project or the team already knows NextAuth.js deeply. For new projects starting today, Better Auth is the better choice.

Billing Checklist

Stripe is the only option I consider for EU SaaS. The European payment method support, VAT handling, and customer portal are not features you want to rebuild yourself.

[ ] Stripe Customer created on signup — immediately, even before the first payment
[ ] Subscription or one-time payments — decide upfront, the data model differs significantly
[ ] Webhook handler with idempotency — Stripe retries for 72 hours; duplicates are guaranteed without this
[ ] Redis deduplication layer — fast check before hitting the database
[ ] Self-service portal — stripe.billingPortal.sessions.create() handles plan changes, cancellations, invoice history
[ ] Free trial logic — trial_period_days in the subscription, enforce feature gating on trial expiry
[ ] Upgrade/downgrade flow — use stripe.subscriptions.update() with proration_behavior: 'create_prorations'
[ ] Invoice generation and delivery — Stripe sends invoice PDFs automatically; for custom invoices, see the PDF generation work I described in the order automation pipeline
[ ] Failed payment recovery (dunning) — three-email sequence, don't immediately revoke access
[ ] Webhook events to handle: payment_intent.succeeded, customer.subscription.updated, customer.subscription.deleted, invoice.payment_failed, invoice.payment_succeeded

The idempotency pattern I use — covering both Redis fast-check and PostgreSQL durable record — is documented in detail in Stripe Webhooks Done Right. I won't repeat it here, but it's non-negotiable: ship it or ship duplicate orders.

Database Checklist

[ ] PostgreSQL — I've used MySQL and SQLite on old projects; I don't anymore
[ ] Drizzle ORM — type-safe queries, plain SQL migrations, no ORM magic
[ ] created_at and updated_at on every table — non-negotiable for debugging production issues
[ ] Soft deletes — deleted_at timestamp column instead of hard DELETE; makes recovery and audit possible
[ ] Migration strategy — Drizzle migrations committed to the repo, run on deploy
[ ] Backup policy — daily automated backups, tested restore at least once before launch
[ ] Connection pooling — PgBouncer or Neon's built-in pooling; raw PostgreSQL connections don't survive serverless

Here's the table structure I start every project with:

// packages/db/schema/base.ts
import { timestamp, uuid } from "drizzle-orm/pg-core";
import { sql } from "drizzle-orm";

// Reusable column set — spread into every table definition
export const baseColumns = {
  id: uuid("id")
    .primaryKey()
    .default(sql`gen_random_uuid()`),
  createdAt: timestamp("created_at", { withTimezone: true }).notNull().defaultNow(),
  updatedAt: timestamp("updated_at", { withTimezone: true })
    .notNull()
    .defaultNow()
    .$onUpdate(() => new Date()),
  deletedAt: timestamp("deleted_at", { withTimezone: true }),
};

// packages/db/schema/users.ts
import { pgTable, text, boolean } from "drizzle-orm/pg-core";
import { baseColumns } from "./base";

export const users = pgTable("users", {
  ...baseColumns,
  email: text("email").notNull().unique(),
  emailVerified: boolean("email_verified").notNull().default(false),
  stripeCustomerId: text("stripe_customer_id").unique(),
  plan: text("plan").notNull().default("free"),
  planActivatedAt: timestamp("plan_activated_at", { withTimezone: true }),
});

Drizzle vs Prisma: I made the switch after Prisma's migration behavior caused a production incident (it tried to recreate an indexed column instead of adding a new one). Drizzle generates raw SQL migrations you can read and verify before running. That's the property I care about most in production. Prisma is friendlier for beginners; Drizzle is what I trust with real data.

API Checklist

[ ] Rate limiting per IP — protect against unauthenticated abuse
[ ] Rate limiting per API key — per-plan limits for authenticated users
[ ] Error responses with machine-readable codes — not just HTTP status codes, but { "error": { "code": "VAT_NUMBER_INVALID", "message": "..." } }
[ ] Cursor-based pagination — offset pagination breaks on large datasets and concurrent writes
[ ] API versioning strategy — even if v1 is the only version, establish the URL pattern now (/api/v1/)
[ ] OpenAPI documentation — Hono has built-in OpenAPI support; use it
[ ] Request validation with Zod — validate inputs before touching the database
[ ] Standard rate limit headers — X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset

For vatnode's public API, I use a two-tier rate limit: 30 requests per minute per API key (enforced per plan in the database), and a hard 60 requests per minute per IP regardless of auth status. The Redis sliding window implementation is worth a dedicated article — and I wrote one: Redis Rate Limiting for APIs. Building a public-facing API is also part of my API integrations work.

A consistent error response format matters more than most developers realize. When a client's code breaks at 2 AM, machine-readable error codes are what makes automated retry logic possible:

// lib/api-error.ts
export class ApiError extends Error {
  constructor(
    public readonly code: string,
    public readonly message: string,
    public readonly statusCode: number = 400,
    public readonly details?: Record<string, unknown>
  ) {
    super(message);
  }
}

// lib/api-response.ts
export function errorResponse(error: ApiError) {
  return Response.json(
    {
      error: {
        code: error.code,
        message: error.message,
        ...(error.details ? { details: error.details } : {}),
      },
    },
    { status: error.statusCode }
  );
}

// Usage:
throw new ApiError("SUBSCRIPTION_REQUIRED", "This endpoint requires an active subscription.", 402);

Email Checklist

[ ] Resend or Mailgun for delivery — never send transactional email from your own SMTP
[ ] Welcome / onboarding sequence — triggered on signup, not a bulk newsletter
[ ] Email verification — required before first meaningful action
[ ] Payment confirmation — immediately after invoice.payment_succeeded
[ ] Failed payment recovery — day 1, day 3, day 7; vary the subject and body
[ ] Subscription cancellation confirmation — acknowledge it, include the end date and data export instructions
[ ] Branded HTML templates — React Email for component-based email templates
[ ] Plain text fallback — some clients don't render HTML; always include it

I use Resend with React Email on all current projects. The developer experience is significantly better than Mailgun templates, and the deliverability is comparable. Here's the email client setup:

// lib/email.ts
import { Resend } from "resend";
import { MagicLinkEmail } from "@/emails/magic-link";
import { PaymentConfirmationEmail } from "@/emails/payment-confirmation";

const resend = new Resend(process.env.RESEND_API_KEY!);

export async function sendMagicLinkEmail({ email, url }: { email: string; url: string }) {
  await resend.emails.send({
    from: "noreply@yourdomain.com",
    to: email,
    subject: "Your sign-in link",
    react: MagicLinkEmail({ url }),
  });
}

export async function sendPaymentConfirmation({
  email,
  invoiceUrl,
  amount,
  currency,
}: {
  email: string;
  invoiceUrl: string;
  amount: number;
  currency: string;
}) {
  const formatted = new Intl.NumberFormat("en-US", {
    style: "currency",
    currency: currency.toUpperCase(),
  }).format(amount / 100); // Stripe amounts are in cents

  await resend.emails.send({
    from: "billing@yourdomain.com",
    to: email,
    subject: `Payment confirmed — ${formatted}`,
    react: PaymentConfirmationEmail({ invoiceUrl, amount: formatted }),
  });
}

Monitoring and Observability Checklist

[ ] Sentry — error tracking with source maps; configure SENTRY_DSN in environment
[ ] Uptime monitoring — BetterUptime or UptimeRobot on all public endpoints; alert threshold 1 minute
[ ] Structured logging — JSON logs with correlation IDs so you can trace a request across services
[ ] Performance monitoring — Vercel Analytics or self-hosted Plausible for the frontend; Sentry performance for the API
[ ] Health check endpoint — GET /api/health that checks DB connectivity and returns 200 or 503
[ ] Alert channels — Telegram bot for critical errors, email for daily summaries

Correlation IDs are the monitoring item that developers consistently skip and consistently regret. When a user reports an error, "I got a 500 error at around 3 PM" is not debuggable without a correlation ID tying the frontend request to the backend logs.

// middleware.ts (Next.js)
import { NextRequest, NextResponse } from "next/server";
import { v4 as uuidv4 } from "uuid";

export function middleware(request: NextRequest) {
  const correlationId = request.headers.get("x-correlation-id") ?? uuidv4();

  const response = NextResponse.next();
  // Pass through to Server Components and API routes
  response.headers.set("x-correlation-id", correlationId);

  return response;
}

Then in every Server Action or API route:

const correlationId = request.headers.get("x-correlation-id");
console.log(JSON.stringify({ level: "info", correlationId, event: "order.created", orderId }));

Security Checklist

[ ] HTTPS enforced — redirect HTTP to HTTPS at the infrastructure level, not in application code
[ ] Content Security Policy headers — use next.config.ts headers configuration, start with report-only mode
[ ] SQL injection protection — Drizzle ORM parameterizes all queries; never interpolate user input into raw SQL
[ ] XSS protection — React escapes by default; audit any dangerouslySetInnerHTML usage
[ ] CSRF protection — Better Auth handles this for session-based auth; verify for any custom endpoints
[ ] Secrets management — environment variables only, never committed to the repo; use Vercel env vars or Doppler
[ ] Dependency audit — npm audit in CI on every PR
[ ] Rate limiting on all mutating endpoints — not just auth; account update, file upload, anything that changes state
[ ] Input validation on the server — Zod schemas on all API inputs; never trust the client

// next.config.ts — security headers
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  async headers() {
    return [
      {
        source: "/(.*)",
        headers: [
          {
            key: "X-Frame-Options",
            value: "DENY",
          },
          {
            key: "X-Content-Type-Options",
            value: "nosniff",
          },
          {
            key: "Referrer-Policy",
            value: "strict-origin-when-cross-origin",
          },
          {
            key: "Permissions-Policy",
            value: "camera=(), microphone=(), geolocation=()",
          },
          // Start with report-only, then enforce once you're confident
          {
            key: "Content-Security-Policy-Report-Only",
            value: [
              "default-src 'self'",
              "script-src 'self' 'unsafe-inline'", // Tighten this after audit
              "style-src 'self' 'unsafe-inline'",
              "img-src 'self' data: https:",
              "connect-src 'self' https://api.stripe.com",
            ].join("; "),
          },
        ],
      },
    ];
  },
};

export default nextConfig;

SEO and Analytics Checklist

[ ] Server-side rendering for all landing pages — Next.js App Router does this by default
[ ] sitemap.xml generated dynamically — app/sitemap.ts with all public routes
[ ] robots.txt — block /api/*, /dashboard/*, allow everything else
[ ] Open Graph tags — title, description, image on every public page
[ ] GA4 server-side tracking — client-side tracking loses 30–60% of conversions to adblockers and iOS
[ ] Structured data (JSON-LD) — at minimum WebSite and Organization schemas on the landing page
[ ] Canonical URLs — especially if you have locale-prefixed routes

For the GA4 server-side tracking implementation I use in production, including the Measurement Protocol setup and deduplication with Meta CAPI, that's a full topic on its own — I cover it in the Server-Side Tracking article.

What to Build vs. What to Buy

This is where projects waste the most time. Building auth, email delivery, or payment processing from scratch is not a competitive advantage. It's technical debt with no upside.

Category	Decision	Why
Auth	Better Auth library	Rolling your own means managing sessions, hashing, OAuth, CSRF — months of work and still wrong
Email delivery	Resend or Mailgun	SPF/DKIM/DMARC setup, deliverability reputation, bounce handling — use a service
File storage	S3 or Cloudflare R2	R2 has no egress fees, compatible S3 API; use it
Payments	Stripe only	European payment methods, VAT handling, dispute management — nothing else comes close
Search	Algolia or Typesense	Only if you need full-text search; most SaaS don't need it at launch
Email templates	React Email	Component-based email that renders in all clients
Background jobs	BullMQ	Battle-tested, Redis-backed, excellent TypeScript support
Monitoring	Sentry + UptimeRobot	Both have generous free tiers; set up on day one

The places I do build custom:

Business logic specific to the domain (EU VAT rules, PDF forensics analysis, order pipeline orchestration)
API integrations not covered by existing libraries (PostNord shipping API, Netvisor accounting API)
Rate limiting with product-specific tiers (covered in the Redis article)

Vercel: What Works and What Doesn't

I deploy Next.js apps to Vercel by default. The DX is excellent — preview deployments, edge functions, automatic SSL. But there are real constraints to plan for:

Works well:

Server Components and Server Actions with standard rendering
API routes that complete in under 25 seconds
Edge middleware for auth and redirects
Static assets and image optimization

Requires workarounds:

Long-running background jobs — use BullMQ on a separate VPS (I run a Vultr instance for workers)
Puppeteer for PDF generation — bundle size hits function limits; consider a dedicated service or @sparticuz/chromium
Large file processing — Vercel's request body limit is 4.5 MB; use presigned S3 URLs for direct browser-to-S3 uploads instead

For vatnode, the Next.js frontend and API routes run on Vercel; the BullMQ workers and long-running processes run on a separate Node.js service deployed to Vultr — as described in detail in the self-hosting on a VPS article.

Honest Time Estimates

These are real numbers from real projects, not optimistic planning estimates.

Week 1–2: Foundation

Auth (Better Auth setup, email verification, OAuth): 3–4 days
Database schema (users, subscriptions, core tables): 2 days
Stripe integration (customer creation, subscription, webhook handler with idempotency): 3–4 days
Base UI (layout, nav, dashboard shell, auth pages): 2 days

Week 3–6: Core Features
This is the variable part. For vatnode, the core feature (VAT validation with Redis caching, rate limiting, VIES integration) took 2 weeks. For HTPBE?, the 5-layer PDF forensics engine took 3 weeks to get right across 7 iterations of the algorithm. Your product's complexity determines this range.

Week 7–8: Production Readiness

Error monitoring (Sentry integration, alert setup): 1 day
Performance audit (Core Web Vitals, database query optimization): 2 days
Security review (CSP headers, dependency audit, secrets audit): 1 day
Email sequences (welcome, payment confirmation, failed payment recovery): 2 days
Documentation (internal runbook, API documentation): 1 day

Total to a production-ready MVP: 6–8 weeks.

Not 2 weeks like some frameworks promise. Not 6 months like agencies quote. 6–8 weeks for a solid foundation plus a working core feature set, if you're a senior developer who's done it before.

The Complete Checklist (Summary)

Auth

[ ] Email + password with bcrypt (12+ rounds)
[ ] Magic links
[ ] OAuth: Google, GitHub
[ ] Database sessions (not JWT-only)
[ ] Rate limiting on all auth endpoints
[ ] Email verification before first login
[ ] Password reset with expiring single-use tokens
[ ] Account deletion (GDPR)

Billing

[ ] Stripe Customer on signup
[ ] Subscription or one-time payment model
[ ] Webhook idempotency (Redis + PostgreSQL)
[ ] Self-service billing portal
[ ] Free trial with feature gating
[ ] Upgrade/downgrade with proration
[ ] Dunning sequence for failed payments
[ ] All five critical webhook events handled

Database

[ ] PostgreSQL with Drizzle ORM
[ ] created_at, updated_at, deleted_at on every table
[ ] Soft deletes
[ ] Migrations in version control
[ ] Automated daily backups with tested restore
[ ] Connection pooling

API

[ ] Rate limiting per IP and per API key
[ ] Machine-readable error codes
[ ] Cursor-based pagination
[ ] API versioning (/api/v1/)
[ ] OpenAPI documentation
[ ] Zod validation on all inputs
[ ] Standard rate limit headers

Email

[ ] Resend or Mailgun for delivery
[ ] Welcome sequence
[ ] Email verification
[ ] Payment confirmation
[ ] Failed payment recovery (3-email sequence)
[ ] Cancellation confirmation
[ ] React Email HTML templates with plain text fallback

Monitoring

[ ] Sentry error tracking with source maps
[ ] Uptime monitoring with 1-minute alert threshold
[ ] Structured JSON logs with correlation IDs
[ ] Health check endpoint
[ ] Alert channel (Telegram or similar)

Security

[ ] HTTPS enforced at infrastructure level
[ ] Content Security Policy (start report-only)
[ ] Parameterized queries (ORM)
[ ] Secrets in environment variables only
[ ] npm audit in CI
[ ] Rate limiting on all mutating endpoints
[ ] Server-side input validation

SEO and Analytics

[ ] Server-side rendered landing pages
[ ] Dynamic sitemap.xml
[ ] robots.txt
[ ] Open Graph tags on all public pages
[ ] GA4 server-side tracking
[ ] Structured data (JSON-LD)
[ ] Canonical URLs

If you're building a SaaS for the EU market, you'll run into every item on this list — plus the EU-specific ones like VAT compliance and GDPR that didn't make it into the generic sections. I've shipped this stack across vatnode, HTPBE?, pi-pi, and pikkuna.fi. The checklist isn't theory; it's what I actually verify before I consider a product launch-ready.

If you need a senior developer who can own this end-to-end — architecture through launch and beyond — get in touch. I build production-ready products, not MVPs that need to be rewritten in six months. Available for freelance projects and long-term engagements.

Common PDF Editing Tools and How We Detect Their Traces

Iurii Rogulia — Fri, 22 May 2026 10:00:27 +0000

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.

Every PDF editing tool leaves traces in the files it processes. These “fingerprints” — embedded in metadata, file structure, and processing patterns — reveal which applications created and modified PDF documents.

Understanding these traces is essential for PDF forensics and document fraud detection. By analyzing tool fingerprints, forensic analysts can identify editing tools, detect modifications, and reconstruct document processing history.

This article explores how PDF editing works technically, which tools leave which traces, and how forensic analysis detects editing tool usage. Whether you are a security researcher, IT forensics professional, or curious technical user, this deep-dive explains the technical details behind PDF tool detection.

Every Edit Leaves a Trace

PDF editing is not invisible. Every tool that creates or modifies a PDF leaves distinctive markers:

Metadata fingerprints: Application names and versions in metadata
Structural signatures: Tool-specific file structure patterns
Processing artifacts: Editing traces in PDF structure
Version markers: PDF specification versions used

These traces persist even when content appears unchanged, making tool detection possible through forensic analysis.

As ResearchGate research shows, tool fingerprinting is a reliable method for detecting PDF modifications.

How PDF Editing Works Technically

Understanding PDF structure helps explain how editing leaves traces:

Incremental Updates

How it works:

PDFs can be modified using incremental updates
Changes are appended to file without rewriting entire document
Original content remains, new content added
Cross-reference table updated to point to new content

Forensic value:

Incremental updates create revision history
Multiple updates indicate multiple editing sessions
Update sequence reveals editing timeline
Original content preserved for comparison

Detection:

Multiple cross-reference tables indicate updates
Incremental update markers show modification points
Object version tracking reveals editing history

Object Modification

How it works:

PDFs consist of objects (text, images, fonts, etc.)
Editing modifies or adds objects
Object references updated in cross-reference table
Deleted objects may remain in file (marked as deleted)

Forensic value:

Object modifications reveal editing activity
Deleted objects provide editing history
Object references show modification scope
Object structure reveals editing methods

Detection:

Cross-reference table analysis shows object changes
Deleted object markers indicate removals
Object structure analysis reveals modifications

Stream Editing

How it works:

PDF content stored in streams (compressed data)
Editing may modify stream content
Stream compression and encoding reveal processing
Stream dictionaries contain processing information

Forensic value:

Stream modifications indicate content changes
Compression methods reveal processing tools
Stream dictionaries contain tool information
Encoding methods show processing history

Detection:

Stream analysis reveals modifications
Compression fingerprinting identifies tools
Dictionary analysis shows processing information

As Forensic Focus discussions explain, understanding PDF structure is essential for forensic analysis.

Common PDF Editing Tools and Their Fingerprints

Different tools leave distinctive traces:

Adobe Acrobat (Pro, DC, Reader)

Metadata fingerprints:

Producer: “Adobe Acrobat” or “Adobe Acrobat Pro”
Creator: Original application (if converted)
PDF version: Typically 1.4 or higher
Application version: Included in metadata

Structural signatures:

Standard PDF structure
Incremental updates when editing
Cross-reference table patterns
Object organization

Processing patterns:

Linearization for web optimization
Metadata preservation
Signature support
Form field handling

Detection:

Producer field identifies Adobe products
Version information reveals Acrobat version
Processing patterns match Adobe workflows
Structural signatures consistent with Adobe tools

Foxit PhantomPDF

Metadata fingerprints:

Producer: “Foxit” or “Foxit PhantomPDF”
Creator: Original application
PDF version: Varies by version
Application identification: Foxit-specific markers

Structural signatures:

Foxit-specific object patterns
Custom metadata fields
Processing artifacts
Version-specific structures

Processing patterns:

Form handling methods
Annotation support
Signature implementation
Optimization techniques

Detection:

Producer field identifies Foxit
Structural analysis reveals Foxit patterns
Processing artifacts show Foxit usage
Version markers indicate Foxit version

As Adobe Community discussions note, different tools create distinctive patterns.

Nitro PDF

Metadata fingerprints:

Producer: “Nitro” or “Nitro PDF”
Creator: Source application
PDF version: Typically 1.4+
Nitro-specific markers

Structural signatures:

Nitro processing patterns
Custom metadata
Object organization
File structure

Processing patterns:

Conversion methods
Editing techniques
Optimization approaches
Form handling

Detection:

Producer identification
Structural fingerprinting
Processing pattern analysis
Version detection

Online Editors (iLovePDF, SmallPDF, etc.)

Metadata fingerprints:

Producer: Often generic or service name
Creator: May show original source
PDF version: Varies
Service identification: May include service markers

Structural signatures:

Web-based processing patterns
Conversion artifacts
Service-specific structures
Processing markers

Processing patterns:

Online conversion methods
Server-side processing
Optimization techniques
Format conversion patterns

Detection:

Producer field may identify service
Structural analysis reveals online processing
Processing patterns show web-based editing
Artifacts indicate online tool usage

Privacy note: Online editors may process documents on servers, raising privacy concerns.

LibreOffice Draw

Metadata fingerprints:

Producer: “LibreOffice” or version-specific
Creator: “LibreOffice Draw”
PDF version: Typically 1.4
Application version: Included

Structural signatures:

LibreOffice-specific patterns
Object organization
Processing methods
Version markers

Processing patterns:

Open-source tool patterns
Conversion methods
Optimization techniques
Form handling

Detection:

Producer identification
Structural fingerprinting
Processing pattern recognition
Version detection

Preview (macOS)

Metadata fingerprints:

Producer: “Mac OS X” or version-specific
Creator: Original application
PDF version: Varies
macOS-specific markers

Structural signatures:

macOS processing patterns
Quartz PDF patterns
System-specific structures
Version markers

Processing patterns:

Native macOS methods
System integration
Optimization techniques
Processing artifacts

Detection:

Producer field identifies macOS
Structural analysis reveals macOS patterns
Processing artifacts show system usage
Version markers indicate macOS version

As Quora discussions explain, tool detection requires analyzing multiple indicators.

What Each Tool Leaves Behind

Understanding tool-specific traces:

Producer Field Changes

What it reveals:

Last application that processed PDF
Tool identification
Version information
Processing history

Forensic value:

Identifies editing tools
Shows processing sequence
Reveals tool usage
Detects unexpected applications

Limitations:

Can be spoofed
May not reflect all processing
Some tools do not update producer
Legitimate workflows use multiple tools

Metadata Patterns

Tool-specific metadata:

Application names
Version information
Processing timestamps
Custom metadata fields

Forensic value:

Tool identification
Version detection
Processing timeline
Custom field analysis

Detection:

Metadata field analysis
Pattern recognition
Version matching
Custom field identification

Structural Signatures

File structure patterns:

Object organization
Cross-reference table structure
Stream organization
File layout

Forensic value:

Tool-specific structures
Processing patterns
Editing methods
Optimization techniques

Detection:

Structural analysis
Pattern matching
Comparison with known patterns
Anomaly detection

As OPSWAT reports, structural analysis reveals tool-specific patterns.

Advanced Techniques

Sophisticated forensic analysis methods:

Incremental Save Analysis

How it works:

Analyzes incremental update sequence
Identifies editing sessions
Tracks modification timeline
Reveals editing history

Forensic value:

Editing session identification
Timeline reconstruction
Modification tracking
History analysis

Detection:

Cross-reference table analysis
Update marker examination
Object version tracking
Sequence analysis

Cross-Reference Table Examination

How it works:

Analyzes cross-reference table structure
Identifies object references
Detects modifications
Reveals editing patterns

Forensic value:

Modification detection
Object change tracking
Structure analysis
Editing method identification

Detection:

Table structure analysis
Reference pattern examination
Anomaly detection
Comparison with originals

Object Tree Analysis

How it works:

Examines PDF object hierarchy
Analyzes object relationships
Identifies modifications
Tracks object changes

Forensic value:

Modification detection
Editing method identification
Structure analysis
Change tracking

Detection:

Object tree parsing
Relationship analysis
Modification identification
Pattern recognition

As Foxit documentation shows, advanced analysis requires deep PDF structure knowledge.

Limitations and Challenges

Tool detection has limitations:

Spoofing

Challenge:

Metadata can be manipulated
Producer fields can be changed
Structural patterns can be mimicked
Tool identification can be spoofed

Mitigation:

Analyze multiple indicators
Check structural consistency
Check metadata against structure
Use comprehensive analysis

Tool Evolution

Challenge:

Tools update and change patterns
New versions create new signatures
Patterns evolve over time
Detection methods need updates

Mitigation:

Maintain tool signature database
Update detection patterns
Analyze version-specific markers
Continuous pattern learning

Legitimate Workflows

Challenge:

Multiple tools used legitimately
Processing chains create complex patterns
Normal workflows involve multiple tools
Distinguishing legitimate from suspicious

Mitigation:

Context-aware analysis
Workflow pattern recognition
Legitimate pattern identification
Suspicious pattern detection

False Positives

Challenge:

Legitimate edits trigger detection
Normal processing creates patterns
Tool usage may be expected
Context matters for interpretation

Mitigation:

Confidence scoring
Context consideration
Pattern validation
Manual review for ambiguous cases

How HTPBE? Uses This Knowledge

HTPBE?’s algorithm leverages tool detection:

Multi-Indicator Analysis

Combines:

Producer field identification
Metadata pattern analysis
Structural signature detection
Processing pattern recognition

Benefits:

More accurate tool identification
Reduced false positives
Comprehensive analysis
Reliable detection

Tool Fingerprint Database

Maintains:

Known tool signatures
Version-specific patterns
Processing artifacts
Structural markers

Benefits:

Accurate tool identification
Version detection
Pattern matching
Continuous updates

Confidence Scoring

Provides:

Tool identification confidence
Pattern match strength
Detection reliability
Interpretation guidance

Benefits:

Clear results
Actionable information
Reduced ambiguity
Better decision-making

Conclusion

PDF editing tools leave distinctive traces in the files they process. These fingerprints — in metadata, structure, and processing patterns — enable forensic analysis to identify editing tools and detect modifications.

Understanding tool detection helps:

Identify editing tools: Know which applications processed documents
Detect modifications: Recognize editing activity
Reconstruct history: Understand document processing timeline
Check authenticity: Confirm expected tool usage

Tool detection is one layer of comprehensive PDF tamper detection. Combined with metadata analysis, signature fraud detection, and structural examination, it provides powerful forensic capabilities.

How to Handle VIES Downtime in Your Application

Iurii Rogulia — Fri, 22 May 2026 09:00:29 +0000

Originally published at vatnode.dev. The version on vatnode.dev is the canonical source — refer to it for the latest content.

VIES national nodes go offline. It is not an edge case — it happens regularly, especially for Germany, which is both the most important EU market and one of the most unreliable VIES nodes. Here is how to build a system that handles it correctly.

Why VIES goes down and how often

VIES is not a single system — it is a network of 27 national nodes, each operated by a member state's tax authority. When you query VIES for an Irish VAT number, the European Commission infrastructure routes the request to Ireland's Revenue Commissioners system in real time. If that system is unavailable, VIES returns an error.

Individual nodes go offline for planned maintenance (typically outside business hours), for unplanned outages, and in Germany's case, for rate limiting — the BZSt node throttles requests during peak periods. Outages can last minutes or hours. There is no official status page for VIES node availability.

The VIES_UNAVAILABLE error

When the vatnode API cannot reach VIES for a given country, it returns HTTP 503 with a structured error body:

{
  "error": {
    "code": "VIES_UNAVAILABLE",
    "message": "The VIES service for IE is temporarily unavailable. Retry later."
  }
}

This is distinct from an invalid VAT number (HTTP 200 with "valid": false) or a format error (HTTP 400 with INVALID_FORMAT). A 503 always means "try again later" — not "this VAT number is invalid".

The right pattern: queue, not block

The most common mistake is blocking a checkout or invoice on VIES unavailability. This is wrong for two reasons:

The customer is almost certainly legitimate. VIES being down does not mean the VAT number is invalid. The customer provided it in good faith and their registration is almost certainly still active.
You cannot verify either way. Blocking is not a safety measure — it is just friction that loses you a sale.

The correct approach: allow the transaction to proceed, apply standard VAT (the safe default), and queue an async job to re-validate when VIES recovers.

async function validateVatForCheckout(vatId: string, customerId: string) {
  const res = await fetch(
    `https://api.vatnode.dev/v1/vat/${encodeURIComponent(vatId)}`,
    { headers: { Authorization: `Bearer ${process.env.VATNODE_API_KEY}` } }
  )

  if (res.status === 503) {
    // VIES unavailable — queue for retry, do not block
    await queue.add('validate-vat-retry', {
      vatId,
      customerId,
      scheduledFor: Date.now() + 5 * 60 * 1000, // retry in 5 minutes
    })

    return {
      valid: null,       // unknown — pending retry
      vatRate: 0.20,     // apply standard VAT in the meantime
      requiresRetry: true,
    }
  }

  const data = await res.json()
  return {
    valid: data.valid,
    vatRate: data.valid ? 0 : 0.20,
    checkId: data.checkId,
    requiresRetry: false,
  }
}

Germany: BZSt fallback

Germany is a special case. The VIES DE node has historically been rate-limited or unavailable more frequently than other member states. The German Bundeszentralamt für Steuern (BZSt) operates a separate VAT validation service — eVatR — that vatnode uses as an automatic fallback.

When you validate a German VAT number (prefix DE) and the VIES DE node is unavailable, vatnode automatically retries against BZSt. If BZSt responds, the response includes "source": "BZST" instead of "source": "VIES". Note that BZSt returns valid/invalid status only — company name and address are not available from this source.

This means German VAT numbers almost never return VIES_UNAVAILABLE from vatnode — the BZSt fallback keeps the validation working even when the VIES DE node is down.

Retry strategy

When VIES is unavailable, a good retry strategy uses exponential backoff with a maximum delay. VIES outages typically resolve within 30–60 minutes:

// Retry intervals (minutes): 5, 15, 30, 60, 120
// After 5 retries (~3.5 hours), flag for manual review

const RETRY_DELAYS = [5, 15, 30, 60, 120]

async function scheduleVatRetry(vatId: string, customerId: string, attempt = 0) {
  if (attempt >= RETRY_DELAYS.length) {
    // Flag for manual review after exhausting retries
    await flagForManualReview({ vatId, customerId })
    return
  }

  const delayMs = RETRY_DELAYS[attempt] * 60 * 1000
  await queue.add(
    'validate-vat-retry',
    { vatId, customerId, attempt: attempt + 1 },
    { delay: delayMs }
  )
}

If you are considering moving away from a direct SOAP connection to VIES, the VIES REST API alternative with automatic fallback covers the migration path and what changes in your codebase.

Build a resilient VAT integration with vatnode

vatnode handles retries, BZSt fallback, and structured error codes so your application can implement the right pattern. Free plan, 100 requests/month.

Get Free API Key · Error Code Reference

Stripe Webhooks: Idempotency, Retries, and Queue Setup

Iurii Rogulia — Fri, 22 May 2026 07:00:27 +0000

Stripe sent one webhook. Your database has three orders. What happened?

This is not a hypothetical. I've seen it in production — on vatnode.dev, on pikkuna.fi, on pi-pi.ee. The Stripe webhook hits your endpoint, your server takes 800ms to respond, Stripe times out and queues a retry. Meanwhile your server did complete the work. Now you have a duplicate. Then another one arrives 30 minutes later.

The naive implementation — parse the JSON, run your business logic, return 200 — fails in ways that only show up under real traffic. Here's what production actually looks like.

Why the Naive Implementation Breaks

Stripe's retry policy is more aggressive than most developers expect. If your endpoint returns anything other than a 2xx status code, or takes longer than 30 seconds to respond, Stripe retries. The schedule: immediately, then at 5 minutes, 30 minutes, 2 hours, 5 hours, 10 hours, and so on — up to 72 hours and roughly 15–18 total attempts.

That means if your server returned 500 at 9 AM on Monday due to a database hiccup, Stripe will still be trying to deliver the same event on Tuesday morning. If your server is back up, it will process the event — possibly creating a duplicate subscription, a duplicate order, or sending a duplicate email to your customer.

The naive handler looks like this:

// app/api/webhooks/stripe/route.ts — DON'T do this
export async function POST(request: Request) {
  const body = await request.json(); // Wrong: parsed body won't verify
  const event = body as Stripe.Event;

  if (event.type === "payment_intent.succeeded") {
    await createOrder(event.data.object); // No idempotency check
  }

  return new Response("ok", { status: 200 });
}

Three problems here: no signature verification, no protection against replay attacks, and synchronous processing that blocks the response while your business logic runs. If createOrder takes 3 seconds and Stripe's timeout is strict, you'll get retries even when the order was created successfully.

name="How to handle Stripe webhooks reliably in production"
totalTime="PT3H"
tools={[
"Next.js 16",
"TypeScript",
"Stripe SDK",
"BullMQ",
"ioredis",
"Drizzle ORM",
"PostgreSQL",
]}
steps={[
{
name: "Verify the signature using raw bytes",
text: "Use request.arrayBuffer() — not request.json() — to get the raw body before passing it to stripe.webhooks.constructEvent. Parsing the body first changes the bytes and makes signature verification always fail.",
},
{
name: "Implement dual-layer idempotency",
text: "Store processed Stripe event IDs in PostgreSQL as the source of truth. Add a Redis pre-check layer for sub-millisecond lookups on hot paths. Return 200 immediately when a duplicate is detected.",
},
{
name: "Enqueue the event with BullMQ",
text: "Return 200 from the HTTP handler within 50ms by enqueuing to BullMQ using event.id as the jobId for deduplication. Never run business logic synchronously inside the webhook handler.",
},
{
name: "Process events in a separate worker",
text: "Run a BullMQ worker with concurrency 5 that handles payment_intent.succeeded, customer.subscription.deleted, and invoice.payment_failed. Double-check idempotency inside the worker to cover edge cases like mid-job restarts.",
},
{
name: "Wrap critical handlers in transactions",
text: "Use a database transaction for payment_intent.succeeded so that partial writes never leave inconsistent state. Send confirmation emails outside the transaction — a failed email shouldn't roll back the order.",
},
{
name: "Test with Stripe CLI locally",
text: "Use stripe listen --forward-to localhost:3000/api/webhooks/stripe and stripe trigger payment_intent.succeeded to replay events. Verify idempotency by re-sending the same event ID and confirming the duplicate response.",
},
]}
/>

Idempotency — The Foundation

slug="api-integrations"
text="Need a production-grade Stripe webhook pipeline — idempotency, BullMQ, signature verification, retry handling — wired into your SaaS or e-commerce stack? This is what I build."
/>

Before any queue, before any worker, you need idempotency: the guarantee that processing the same event twice produces the same result as processing it once.

Stripe makes this straightforward — every event has a unique id field (e.g., evt_1OqXyz...). Store this ID when you process the event. On subsequent attempts, check the store first and short-circuit.

I use PostgreSQL for durable idempotency keys and Redis for a fast pre-check layer. Here's the Drizzle ORM schema:

// packages/db/schema/webhook-events.ts
import { pgTable, text, timestamp, jsonb } from "drizzle-orm/pg-core";

export const webhookEvents = pgTable("webhook_events", {
  id: text("id").primaryKey(), // Stripe event ID — evt_1OqXyz...
  type: text("type").notNull(), // payment_intent.succeeded, etc.
  processedAt: timestamp("processed_at").notNull().defaultNow(),
  payload: jsonb("payload").notNull(),
});

And the idempotency check — run this before any business logic:

// lib/webhook-idempotency.ts
import { db } from "@/packages/db";
import { webhookEvents } from "@/packages/db/schema/webhook-events";
import { eq } from "drizzle-orm";
import { redis } from "@/lib/redis"; // ioredis instance

export async function isAlreadyProcessed(eventId: string): Promise<boolean> {
  // Fast path: Redis check first (sub-millisecond)
  const cached = await redis.get(`webhook:processed:${eventId}`);
  if (cached) return true;

  // Slow path: database check (handles Redis eviction or restarts)
  const existing = await db
    .select({ id: webhookEvents.id })
    .from(webhookEvents)
    .where(eq(webhookEvents.id, eventId))
    .limit(1);

  if (existing.length > 0) {
    // Restore to Redis cache so future checks are fast
    await redis.set(`webhook:processed:${eventId}`, "1", "EX", 86400 * 7);
    return true;
  }

  return false;
}

export async function markAsProcessed(
  eventId: string,
  type: string,
  payload: unknown
): Promise<void> {
  // Write to DB first — this is the source of truth
  await db.insert(webhookEvents).values({
    id: eventId,
    type,
    payload,
  });

  // Then cache in Redis for fast future lookups
  await redis.set(`webhook:processed:${eventId}`, "1", "EX", 86400 * 7);
}

Signature Verification in Next.js App Router

Here's the subtle thing that breaks almost every Next.js webhook tutorial: request.json() returns a parsed object. Stripe's signature verification requires the raw bytes of the original request body. Once parsed, the signature check will always fail.

In the Pages Router, you'd disable bodyParser. In the App Router, you use request.arrayBuffer():

// app/api/webhooks/stripe/route.ts
import Stripe from "stripe";
import { NextResponse } from "next/server";
import { isAlreadyProcessed } from "@/lib/webhook-idempotency";
import { webhookQueue } from "@/lib/webhook-queue";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!, {
  apiVersion: "2025-01-27.acacia",
});

const webhookSecret = process.env.STRIPE_WEBHOOK_SECRET!;

export async function POST(request: Request) {
  // arrayBuffer() gives us raw bytes — required for signature verification
  const rawBody = await request.arrayBuffer();
  const signature = request.headers.get("stripe-signature");

  if (!signature) {
    return NextResponse.json({ error: "Missing signature" }, { status: 400 });
  }

  let event: Stripe.Event;

  try {
    // Convert ArrayBuffer to Buffer for the Stripe SDK
    event = stripe.webhooks.constructEvent(Buffer.from(rawBody), signature, webhookSecret);
  } catch (err) {
    console.error("Webhook signature verification failed:", err);
    return NextResponse.json({ error: "Invalid signature" }, { status: 400 });
  }

  // Check idempotency before doing anything else
  const alreadyProcessed = await isAlreadyProcessed(event.id);
  if (alreadyProcessed) {
    // Return 200 so Stripe stops retrying — this is intentional
    return NextResponse.json({ received: true, duplicate: true });
  }

  // Enqueue the event — don't process synchronously
  await webhookQueue.add(
    event.type,
    { event },
    {
      jobId: event.id, // BullMQ deduplicates by jobId within the active window
      attempts: 5,
      backoff: { type: "exponential", delay: 5000 },
    }
  );

  // Return immediately — Stripe considers this success
  return NextResponse.json({ received: true });
}

Two things to notice. First, the idempotency check runs before enqueuing — so if Stripe retries and the job is still in the queue (not yet processed), you return 200 and BullMQ's jobId deduplication handles the rest. Second, the endpoint returns immediately after enqueuing. This response time is typically under 50ms, well within Stripe's timeout window.

BullMQ Queue Architecture

Processing webhooks synchronously in the HTTP handler means your response time is tied to every downstream API call — CRM updates, email sends, database writes. One slow dependency and you're getting retries.

The right architecture: webhook endpoint enqueues, a separate worker processes.

// lib/webhook-queue.ts
import { Queue } from "bullmq";
import { redis } from "@/lib/redis";

export const webhookQueue = new Queue("stripe-webhooks", {
  connection: redis,
  defaultJobOptions: {
    attempts: 5,
    backoff: {
      type: "exponential",
      delay: 5000, // 5s, 10s, 20s, 40s, 80s
    },
    removeOnComplete: { count: 1000 }, // Keep last 1000 for debugging
    removeOnFail: false, // Keep failed jobs in DLQ for inspection
  },
});

// workers/stripe-webhook.worker.ts
import { Worker, Job } from "bullmq";
import Stripe from "stripe";
import { redis } from "@/lib/redis";
import { isAlreadyProcessed, markAsProcessed } from "@/lib/webhook-idempotency";
import { handlePaymentSucceeded } from "./handlers/payment-succeeded";
import { handleSubscriptionDeleted } from "./handlers/subscription-deleted";
import { handleInvoicePaymentFailed } from "./handlers/invoice-payment-failed";

const worker = new Worker(
  "stripe-webhooks",
  async (job: Job<{ event: Stripe.Event }>) => {
    const { event } = job.data;

    // Double-check idempotency inside the worker — edge case: worker restart mid-job
    const alreadyProcessed = await isAlreadyProcessed(event.id);
    if (alreadyProcessed) {
      return { skipped: true, reason: "duplicate" };
    }

    switch (event.type) {
      case "payment_intent.succeeded":
        await handlePaymentSucceeded(event.data.object as Stripe.PaymentIntent);
        break;

      case "customer.subscription.deleted":
        await handleSubscriptionDeleted(event.data.object as Stripe.Subscription);
        break;

      case "invoice.payment_failed":
        await handleInvoicePaymentFailed(event.data.object as Stripe.Invoice);
        break;

      default:
        console.log(`Unhandled webhook type: ${event.type}`);
        return { skipped: true, reason: "unhandled_type" };
    }

    // Mark processed only after the handler succeeds
    // If the handler throws, BullMQ retries the job — we don't mark it done
    await markAsProcessed(event.id, event.type, event.data.object);

    return { processed: true };
  },
  {
    connection: redis,
    concurrency: 5,
  }
);

worker.on("failed", (job, err) => {
  // After all retries exhausted, alert your team
  console.error(`Webhook job ${job?.id} failed permanently:`, err);
});

The dead letter queue behavior is built into BullMQ — failed jobs (after all retries) stay in the failed state. I keep a Telegram alert on the failed event so I know immediately when something needs manual intervention.

Handling the Key Events

payment_intent.succeeded — the most critical handler. Wrap it in a database transaction so partial writes don't leave inconsistent state:

// workers/handlers/payment-succeeded.ts
import Stripe from "stripe";
import { db } from "@/packages/db";
import { orders, users } from "@/packages/db/schema";
import { eq } from "drizzle-orm";

export async function handlePaymentSucceeded(paymentIntent: Stripe.PaymentIntent): Promise<void> {
  const customerId = paymentIntent.customer as string;
  const metadata = paymentIntent.metadata;

  await db.transaction(async (tx) => {
    await tx.insert(orders).values({
      stripePaymentIntentId: paymentIntent.id,
      customerId,
      amount: paymentIntent.amount,
      currency: paymentIntent.currency,
      status: "paid",
    });

    if (metadata.plan) {
      await tx
        .update(users)
        .set({ plan: metadata.plan, planActivatedAt: new Date() })
        .where(eq(users.stripeCustomerId, customerId));
    }
  });

  // Send confirmation email outside the transaction — failure here
  // doesn't roll back the order; it just retries the email separately
  await sendOrderConfirmation({ paymentIntentId: paymentIntent.id });
}

customer.subscription.deleted — downgrade the user, don't delete their data. Keep at least 30 days of data post-cancellation. Stripe fires this for both immediate cancellations and end-of-period ones — check cancel_at_period_end to differentiate.

invoice.payment_failed — send a dunning email, don't immediately revoke access. Stripe's Smart Retries will attempt the charge again. Give the customer a grace period to update their payment method.

Testing with Stripe CLI

# Forward all events to your local Next.js dev server
stripe listen \
  --forward-to localhost:3000/api/webhooks/stripe

# Trigger specific events
stripe trigger payment_intent.succeeded
stripe trigger customer.subscription.deleted
stripe trigger invoice.payment_failed

For testing idempotency: copy the event ID from the CLI output and call your endpoint twice with the same payload — the second call should return { received: true, duplicate: true } within milliseconds.

Gotchas That Cost Me Real Time

request.json() silently breaks signature verification. The raw body and the serialized JSON aren't byte-for-byte identical. Always use request.arrayBuffer(). This is the most common issue I see in Next.js webhook implementations.

BullMQ jobId deduplication only covers active jobs. If a job is completed or failed, BullMQ will accept a new job with the same ID. That's why the database idempotency check is still necessary — it covers retries arriving weeks after the original was processed.

STRIPE_WEBHOOK_SECRET differs between environments. The CLI secret (whsec_... with CLI prefix) is different from the dashboard secret. Use separate environment variables for each environment.

Never trust event.data.object amounts without checking currency. EUR amounts are in cents (100 = €1.00). JPY has no minor unit (100 = ¥100). Always pair the amount with the currency field when storing.

What This Looks Like in Production

On vatnode.dev, webhooks hit the endpoint and return within 40–60ms. The BullMQ worker processes the actual subscription logic asynchronously, with 5 concurrent workers handling bursts. Zero duplicate subscriptions created since launch.

On pikkuna.fi, the same architecture drives the full order pipeline — Stripe fires the webhook, the worker triggers Zoho CRM, PostNord shipment creation, Netvisor invoice, and Mailgun confirmation email in sequence. The webhook endpoint returns 200 within 50ms; the full chain completes in under 2 minutes.

If you're building a SaaS or e-commerce platform with Stripe, you'll hit exactly these problems — usually at the worst moment, like during a product launch or after a server restart.

I've built reliable Stripe integrations across several production systems, from subscription SaaS (vatnode.dev) to high-volume international e-commerce (pikkuna.fi). Once the webhook pipeline is solid, the order automation layer on top becomes straightforward — see how the full e-commerce order pipeline works.

If you need a senior developer who can own the payment infrastructure end-to-end — get in touch. I'm available for API integration and e-commerce development projects and long-term engagements.

Related projects: Pikkuna E-commerce Platform — full order pipeline with Stripe, Zoho CRM, and PostNord integration. Vatnode VAT validation SaaS — subscription billing where this webhook architecture is in production.

EU VAT Rates 2026 — Complete Country-by-Country Guide for Developers

Iurii Rogulia — Thu, 21 May 2026 19:30:12 +0000

Originally published at vatnode.dev. The version on vatnode.dev is the canonical source — refer to it for the latest content.

Standard, reduced, super-reduced, and parking VAT rates for all 27 EU member states in 2026. Includes recent changes, local currency, and how to access this data programmatically via the vatnode API or the open-source eu-vat-rates-data package (JavaScript, Python, PHP, Go, Ruby).

Recent rate changes

🇫🇮 Finland — Standard rate raised from 24% to 25.5%. Effective September 2024 · Current standard rate: 25.5%
🇪🇪 Estonia — Standard rate raised from 22% to 24%. Effective January 2024 · Current standard rate: 24%
🇸🇰 Slovakia — Standard rate raised from 20% to 23%. Effective January 2025 · Current standard rate: 23%
🇷🇴 Romania — Standard rate raised from 19% to 21%. Effective January 2025 · Current standard rate: 21%

EU VAT Rates 2026 — All 27 Member States

Rates are sourced daily from the European Commission Tax and Duty Database (TEDB). Last updated: March 2026.

Country	Currency	Standard	Reduced	Super-Red.	Parking
Austria	EUR	20%	10%, 13%, 19%	—	—
Belgium	EUR	21%	6%, 12%	—	12%
Bulgaria	BGN	20%	9%	—	—
Croatia	EUR	25%	5%, 13%	—	—
Cyprus	EUR	19%	5%, 9%	3%	—
Czech Republic	CZK	21%	12%	—	—
Denmark	DKK	25%	—	—	—
Estonia	EUR	24%	9%, 13%	—	—
Finland (Raised from 24% in September 2024)	EUR	25.5%	10%, 13.5%	—	—
France (Multiple rates; DOM territories vary)	EUR	20%	5.5%, 10%	2.1%	—
Germany	EUR	19%	7%	—	—
Greece	EUR	24%	6%, 13%	4%	13%
Hungary	HUF	27%	5%, 18%	—	—
Ireland	EUR	23%	9%, 13.5%	—	—
Italy	EUR	22%	5%, 10%	4%	—
Latvia	EUR	21%	5%, 12%	—	—
Lithuania	EUR	21%	5%, 12%	—	—
Luxembourg	EUR	17%	8%, 14%	3%	14%
Malta	EUR	18%	5%, 7%	—	12%
Netherlands	EUR	21%	9%	—	—
Poland	PLN	23%	5%, 8%	—	—
Portugal (Azores and Madeira have lower rates)	EUR	23%	6%, 13%	6%	13%
Romania	RON	21%	11%	—	—
Slovakia	EUR	23%	5%, 19%	—	—
Slovenia	EUR	22%	5%, 9.5%	—	—
Spain	EUR	21%	10%	4%	—
Sweden	SEK	25%	6%, 12%	—	—

Rate types explained

Standard rate — The main VAT rate that applies to most goods and services. Ranges from 17% (Luxembourg) to 27% (Hungary) across the EU.

Reduced rate — Lower rates that apply to specific categories — typically food, books, medicines, public transport, and cultural services. Countries may have one or two reduced rates.

Super-reduced rate — An even lower rate (below 5%) that a subset of EU countries apply to essential goods. Examples: 2.1% in France for some newspapers and medicines, 3% in Luxembourg.

Parking rate — A transitional rate some countries kept when the EU harmonized VAT rules. Applies to goods and services that were at a reduced rate before the EU's 6th VAT Directive. Only Belgium, Greece, Luxembourg, Malta, and Portugal still use parking rates.

Access VAT rates programmatically

The vatnode API returns the current VAT rates for a country as part of every validation response — no separate rates call needed:

curl https://api.vatnode.dev/v1/vat/FI29845875 \
  -H "Authorization: Bearer $VATNODE_API_KEY"

# countryVat block included in every response:
{
  "countryVat": {
    "vatName": "Arvonlisävero",   // Finnish: "value added tax"
    "vatAbbr": "ALV",             // abbreviation for invoice printing
    "currency": "EUR",
    "standardRate": 25.5,         // updated September 2024
    "reducedRates": [10, 13.5],
    "superReducedRate": null,
    "parkingRate": null,
    "countryVatUpdatedAt": "2026-03-30"
  }
}

You can also query rates directly by country code without validating a VAT number — useful for displaying tax information in your UI:

# Free endpoint — no API key required
curl https://api.vatnode.dev/v1/rates/DE

# Response
{
  "countryCode": "DE",
  "countryName": "Germany",
  "vatName": "Mehrwertsteuer",
  "vatAbbr": "MwSt",
  "currency": "EUR",
  "standardRate": 19,
  "reducedRates": [7],
  "superReducedRate": null,
  "parkingRate": null,
  "countryVatUpdatedAt": "2026-03-30"
}

For a standalone open-source package (no API key, no rate limits), see the EU VAT rates tool available for JavaScript, Python, PHP, Go, and Ruby.

Once you have the correct rate, the next step is confirming the buyer's VAT registration is active. See the guide on how to validate EU VAT numbers programmatically for a complete checkout integration pattern.

Always-current VAT rates via API

vatnode syncs rates daily from the EC TEDB. The rates in your API response are always up to date — including recent changes like Finland's 25.5% and Slovakia's 23%.

Get Free API Key · Rates API Docs · Open-Source Package

How to Check a PDF Before Payment: 7-Step Checklist

Iurii Rogulia — Thu, 21 May 2026 10:00:27 +0000

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.

The moment before you click “Pay” is critical. Once funds are transferred, recovery becomes difficult or impossible. Yet many businesses process payments based on PDF invoices without fraud detection, trusting that what they see is authentic.

This trust is often misplaced. Invoice fraud through PDF modification is a growing threat, with criminals altering invoices to redirect payments to fraudulent accounts. According to the FBI Internet Crime Complaint Center, business email compromise attacks involving modified invoices resulted in losses exceeding $2.7 billion in 2022.

This article provides a practical 7-step checklist to check PDF invoices before making payments. Following this checklist can prevent devastating financial losses and protect your business from payment fraud.

The Moment Before You Click “Pay”

Payment processing is a critical business function, but it is also a prime target for fraudsters. The combination of trust in invoices, time pressure, and the difficulty of recovering funds makes payment fraud highly effective.

The problem:

Invoices look official and are trusted
Time pressure encourages skipping fraud detection
PDFs can be modified without obvious signs
Funds are difficult to recover once transferred

The solution:

Systematic fraud detection before every payment
Multiple fraud detection methods
Independent confirmation channels
Automated PDF tamper detection tools

As Ramp explains, fraud detection is not optional — it is essential for payment security.

Why Fraud Detection Matters

Understanding the risks helps justify fraud detection time:

Fraud Statistics

Average loss: $150,000 per invoice fraud incident
Recovery rate: Less than 10% of funds recovered
Frequency: Increasing year-over-year
Target: All businesses, regardless of size

Common Attack Methods

Email interception: Criminals intercept legitimate invoices
PDF modification: Bank account details changed in PDF
Social engineering: Urgency created to bypass fraud detection
Impersonation: Fake emails from compromised accounts

Consequences

Financial loss: Direct theft of funds
Operational disruption: Payment processing delays
Reputation damage: Loss of vendor trust
Legal issues: Compliance and regulatory problems

As Tipalti reports, fraud detection prevents the majority of payment fraud attempts.

The 7-Step Pre-Payment Fraud Detection Checklist

Use this checklist for every payment:

Step 1: Check Sender Email Address

What to check:

Email address matches vendor records
No slight variations (e.g., vendor@company.com vs vendor@cornpany.com)
Email domain matches vendor website
Sender name matches known contacts

How to check:

Compare with vendor master file
Check previous email correspondence
Check domain through vendor website
Contact vendor if email address changed

Red flags:

New email address without prior notice
Slight variations in domain name
Email from personal account instead of business
Unexpected sender name

Why it matters: Email compromise is the primary attack vector for invoice fraud. Checking sender identity is the first line of defense.

Step 2: Check PDF Metadata for Anomalies

What to check:

Creation and modification dates
Creator and producer applications
Metadata consistency
Unexpected applications

How to check:

Open PDF Properties (File → Properties)
Review creation and modification dates
Check creator and producer fields
Look for unexpected applications

Red flags:

Recent modification of old invoice
Invoice created in unexpected application
Multiple producer entries
Metadata inconsistencies

Why it matters: Metadata reveals document processing history. Anomalies can indicate PDF modification.

Automated option: Use HTPBE? to automatically check metadata and detect modifications — just upload the invoice PDF for instant analysis.

Step 3: Compare Bank Details with Records

What to check:

Bank account number matches vendor records
Routing number is correct
Bank name matches expected institution
SWIFT code (for international payments) is correct

How to check:

Compare with vendor master file
Check previous payment records
Check bank details independently
Confirm with vendor if details changed

Red flags:

New bank account without prior notice
Account number different from records
Bank name changed unexpectedly
Routing number does not match bank

Why it matters: Bank account changes are the primary goal of invoice fraud. Checking account details prevents payment redirection.

Critical: Never trust bank details from email alone. Always check through independent channels.

Step 4: Check Digital Signatures if Present

What to check:

Digital signature presence
Signature validity status
Certificate validity
Signature scope

How to check:

Open PDF in Adobe Acrobat Reader
Look for signature panel or field
Click signature to view status
Check signature validity

Red flags:

Invalid digital signature
Signature missing when expected
Certificate expired or revoked
Signature scope does not cover entire document

Why it matters: Digital signatures provide cryptographic proof of document integrity. Invalid signatures indicate modification.

Note: Not all invoices have digital signatures. When present, they provide strong authenticity proof.

Step 5: Call Vendor to Confirm (Use Known Number)

What to check:

Invoice authenticity
Bank account details
Payment amount
Payment timing

How to check:

Call vendor using known phone number (not from email)
Confirm invoice details
Check bank account information
Confirm payment amount and timing

Red flags:

Vendor cannot confirm invoice
Bank details do not match vendor records
Vendor unaware of invoice
Urgency pressure to skip fraud detection

Why it matters: Independent fraud detection through phone call prevents email-based fraud. Using known numbers prevents phone number spoofing.

Critical: Always use phone numbers from your records, never from emails or invoices.

As ResolvePay explains, fraud detection calls are essential for preventing payment fraud.

Step 6: Check for Duplicate Invoice Numbers

What to check:

Invoice number matches records
No duplicate invoice numbers
Sequential invoice numbering
Invoice number format consistency

How to check:

Check invoice number against records
Search for duplicate invoice numbers
Check invoice numbering sequence
Confirm invoice number format

Red flags:

Duplicate invoice number
Invoice number out of sequence
Invoice number format changed
Missing invoice numbers in sequence

Why it matters: Duplicate invoices can indicate fraud or processing errors. Checking invoice numbers helps detect both.

Step 7: Use automated fraud detection Tools

What to check:

PDF modification detection
Comprehensive analysis
Confidence scoring
Detailed reporting

How to check:

Upload invoice PDF to fraud-detection tool
Review analysis results
Check confidence scores
Examine detailed indicators

Benefits:

Detects modifications manual review misses
Provides confidence scores
Analyzes multiple indicators
Creates fraud detection records

Why it matters: Automated tools provide comprehensive analysis that manual review cannot match. They detect sophisticated modifications and provide objective assessment.

Integration: Use automated fraud detection as part of payment workflow for consistent application.

As PLANERGY notes, automated fraud detection tools are essential for modern payment security.

Red Flags That Should Stop Payment

Certain red flags should immediately halt payment processing:

Critical Red Flags

Stop payment if:

PDF tamper detection shows modification
Bank account details changed without prior notice
Vendor cannot confirm invoice by phone
Digital signature is invalid
Multiple fraud detection failures
Urgency pressure to skip fraud detection

Warning Signs

Investigate before payment:

Sender email address changed
Metadata shows unexpected modifications
Invoice number is duplicate
Payment amount is higher than expected
Payment timing is unusual

When in Doubt

Best practice:

Do not proceed with payment
Investigate further
Check through multiple channels
Get management approval
Document concerns

As InvoiceOwl explains, when in doubt, delay payment until fraud detection is complete.

What to Do If Something Seems Wrong

If fraud detection reveals problems:

Immediate Actions

Stop payment: Halt payment processing immediately
Document findings: Record all detection results
Notify management: Escalate concerns to management
Contact vendor: Check directly with vendor
Investigate further: Determine if fraud or error

Investigation Steps

Review detection results: Examine all indicators
Contact vendor: Check invoice authenticity
Check records: Compare with vendor master file
Review communication: Check email history
Document everything: Keep records of investigation

Resolution

If fraud confirmed:

Notify law enforcement
Report to FBI IC3
Contact bank to attempt recovery
Review security processes
Update fraud detection procedures

If error confirmed:

Process payment with correct details
Update vendor records
Document error resolution
Review processes to prevent recurrence

As Xelix explains, quick action improves fraud prevention and recovery chances.

Creating a fraud-detection workflow

Implementing systematic fraud detection:

Workflow Design

Process steps:

Receive invoice
Check sender email
Check PDF metadata
Compare bank details
Check digital signature (if present)
Call vendor to confirm
Check invoice number
Use automated fraud detection
Approve payment if all checks pass

Automation Opportunities

Automate where possible:

PDF tamper detection (automated tools)
Invoice number checking (database lookup)
Bank detail comparison (vendor master file)
Email fraud detection (sender validation)

Manual steps:

Phone call to vendor
Management approval
Exception handling

Documentation

Maintain records:

detection results
Phone call confirmations
Exception approvals
Fraud incidents

Audit trail:

Complete fraud detection history
Decision documentation
Approval records
Incident reports

Tools and Resources

Fraud Detection tools and resources:

PDF Tamper Detection

HTPBE? provides automated PDF tamper detection with confidence scores — upload any invoice PDF and get instant analysis showing whether the document has been modified. The free web interface requires no signup and processes documents in seconds.

Vendor Management

Vendor master files: Centralized vendor information
Contact databases: Known phone numbers and emails
Payment records: Historical payment information

Communication Channels

Phone fraud detection: Known vendor phone numbers
Secure portals: Vendor document submission
Encrypted email: Secure communication channels

Conclusion

Checking PDF invoices before payment is essential for preventing fraud. The 7-step checklist provides a systematic approach:

Check sender email address
Check PDF metadata for anomalies
Compare bank details with records
Check digital signatures if present
Call vendor to confirm (use known number)
Check for duplicate invoice numbers
Use automated fraud detection tools

Following this checklist prevents the majority of payment fraud attempts. When combined with automated fraud detection tools, it provides comprehensive protection against invoice fraud.

Remember: a few minutes spent checking an invoice can prevent devastating financial losses. When in doubt, delay payment until fraud detection is complete.

Technical SEO for Next.js: SSR, JSON-LD, and Sitemaps

Iurii Rogulia — Thu, 21 May 2026 07:00:26 +0000

I don't offer SEO as a service. But every site I build ships with technical SEO baked in — because it's not marketing, it's engineering. A site that search engines can't crawl or understand is a site that doesn't work properly. In the pikkuna.fi e-commerce build, that meant correct hreflang across 30 languages, server-rendered product pages, and JSON-LD that survived localization. Same principles, scaled up.

slug="mvp-development"
text="Building a Next.js project that needs to rank from day one? SSR, structured data, and sitemaps are part of what I ship — not add-ons."
/>

Server-Side Rendering by Default

Single-page apps with client-side rendering are invisible to most crawlers. Every project I build uses Next.js App Router with server components:

// app/products/[slug]/page.tsx
export default async function ProductPage({
  params
}: {
  params: Promise<{ slug: string }>
}) {
  const { slug } = await params;
  const product = await getProduct(slug);

  return (
    <article>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </article>
  );
}

The HTML arrives fully rendered. No JavaScript required for indexing.

Dynamic Meta Tags

Every page gets proper meta tags generated from actual content:

// app/products/[slug]/page.tsx
export async function generateMetadata({
  params,
}: {
  params: Promise<{ slug: string }>;
}): Promise<Metadata> {
  const { slug } = await params;
  const product = await getProduct(slug);

  return {
    title: `${product.name} | Store`,
    description: product.description.slice(0, 160),
    openGraph: {
      title: product.name,
      description: product.description,
      images: [product.image],
    },
  };
}

This handles SEO meta tags, Open Graph for social sharing, and Twitter cards — all from one function.

JSON-LD Structured Data

Schema.org markup tells search engines exactly what the content represents:

function ProductJsonLd({ product }: { product: Product }) {
  const schema = {
    "@context": "https://schema.org",
    "@type": "Product",
    name: product.name,
    description: product.description,
    image: product.image,
    offers: {
      "@type": "Offer",
      price: product.price,
      priceCurrency: "EUR",
      availability: "https://schema.org/InStock",
    },
  };

  return (
    <script
      type="application/ld+json"
      dangerouslySetInnerHTML={{ __html: JSON.stringify(schema) }}
    />
  );
}

I add appropriate schemas based on content type: Product, Article, Organization, FAQPage, BreadcrumbList.

Automatic Sitemap Generation

Next.js can generate sitemaps from your data:

// app/sitemap.ts
export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  const products = await getAllProducts();

  return [
    { url: "https://example.com", lastModified: new Date() },
    ...products.map((p) => ({
      url: `https://example.com/products/${p.slug}`,
      lastModified: p.updatedAt,
    })),
  ];
}

No plugins, no external services. Just code that generates /sitemap.xml at build time.

This isn't optimization work you hire someone for later. It's the baseline for a properly built website. When I deliver a project, the technical SEO foundation is already there — because skipping it means shipping broken software.

If you want to go further with the indexing layer, read IndexNow in Next.js: Instant Indexing After Every Deploy and llms.txt for AI Discoverability. Together with the patterns above, that's the full stack.

slug="seo-audit"
text="Want this same checklist applied to your existing site? Fixed-fee Technical SEO Audit — keyword research per market, schema, sitemap, hreflang, Core Web Vitals, indexing, broken links, OG images — delivered as a prioritised written report in 5 working days."
/>

For MVP development with this foundation built in from the start — get in touch.

How to Report a Modified PDF to the Sender: A Professional Guide

Iurii Rogulia — Wed, 20 May 2026 10:00:25 +0000

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.

Discovering that a PDF document you received has been modified can be unsettling. Whether it is an invoice, contract, certificate, or payment confirmation, document tampering raises serious concerns about authenticity and trust.

But here is the important thing: a “modified” result does not automatically mean fraud. Many legitimate actions create modifications — re-saving a file, adding digital signatures, converting formats, or making authorized edits. The key is knowing how to communicate professionally and gather more information.

This guide will help you navigate this sensitive situation while maintaining professional relationships.

Understanding HTPBE?’s Modification Confidence

Before reaching out to anyone, understand what this analysis actually tells you:

100% Confidence (Definitive Finding)

When HTPBE? shows 100% Confidence, it means the analysis has found conclusive cryptographic evidence that the PDF was modified after its digital signature was applied. This is a definitive finding — it cannot be a false positive.

This happens when:

A digitally signed PDF was edited after signing
The signature hash no longer matches the document content
There are modifications detected after the signature timestamp

High Confidence

High Confidence indicates strong structural evidence that the PDF was modified after its initial creation. While highly reliable, false positives can occur in some legitimate workflows:

Linearized PDFs (optimized for web viewing)
PDF/A conversion for archival
Re-saving without content changes
Form field filling

Standard Detection

For files without digital signatures, HTPBE?’s analysis examines metadata, cross-reference tables, incremental updates, and other technical indicators. These provide strong evidence but should be considered alongside the document context.

Step 1: Share the Result

The easiest way to start a conversation is to share your HTPBE? result directly with the sender. Every result page has a Share button that generates a shareable link.

When you share a result:

The recipient sees the exact same analysis you see
They can review all technical details themselves
No accusations needed — just “here is what I found”
The conversation starts from a neutral, factual basis

Sample Message with Shared Result

Hi [Name],

I was reviewing the [document type] you sent on [date] as part of my standard detection process. I used htpbe.tech to check the PDF, and it flagged some concerns I wanted to discuss with you.

Here is the analysis report: [paste HTPBE result link]

Could you help me understand if any modifications were made to this document before sending? I want to make sure we are working with the correct version.

Thanks for your help!

[Your Name]

This approach is:

Non-accusatory — you are asking for clarification, not making accusations
Transparent — they see exactly what you see
Professional — you are following a detection process, not singling them out

Step 2: Understanding Their Response

If They Confirm Legitimate Modification

Many modifications are perfectly normal:

Modification Type	Legitimate Reason
Re-saved file	Software auto-save, format conversion
Digital signature added	Normal signing workflow
Form fields filled	Standard form completion
Combined documents	Merging multiple PDFs
Converted from Word	Standard document creation

If their explanation makes sense:

Request documentation of the changes if needed for records
Ask for the original version if your compliance requires it
Update your fraud detection records accordingly

If They Are Unaware of Modifications

This is a red flag that requires escalation:

Request a fresh copy directly from their source system (not email)
Check through an alternative channel — call them directly using a known number
Check for email compromise — fraudsters often intercept emails and modify attachments
Document everything — keep records of all communication

Warning: Invoice fraud often involves intercepting legitimate emails and changing payment details. If an invoice shows unexpected bank account changes along with modification markers, treat this as a serious security incident.

If They Do Not Respond

Send a follow-up after 48–72 hours
Use an alternative contact method (phone call, different email)
Document all communication attempts
Do not proceed with payments or actions based on unchecked documents

Step 3: When You Disagree with the Result

What if you believe this analysis is incorrect? HTPBE? has a Dispute This Result feature specifically for this situation.

How the Dispute Process Works

Click “Dispute This Result” on any result page
Optionally provide your email for follow-up
Submit the dispute

What happens next:

The HTPBE team receives the analysis metadata (filename, scores, technical indicators)
They manually review the file using advanced forensic techniques
If they find the analysis was incorrect, they update the result
If you provided an email, they contact you with their findings

Privacy note: We only receive metadata — your actual PDF content is never transmitted during a dispute.

When to Use Dispute

Use the dispute feature when:

You know the document is original but it shows as modified
The sender confirms no modifications were made
You have additional context HTPBE? might not have considered
The analysis seems inconsistent with the document source

Professional Email Templates

Template 1: Initial Inquiry (Neutral Tone)

Subject: Document Fraud Detection Request — [Document Name/Reference]

Dear [Name],

I hope this message finds you well. I am writing regarding the [document type] you sent on [date].

As part of my standard document fraud detection process, I ran the file through htpbe.tech. The analysis detected some indicators that suggest the file may have been modified after its original creation.

You can view the full analysis here: [HTPBE Result Link]

This is not necessarily a concern — many legitimate actions like adding signatures or converting formats can trigger these indicators. However, I wanted to reach out to confirm:

Were any modifications made to this document before sending?

Could you check that this is the correct and final version?

If available, could you provide the document directly from your source system?

I appreciate your understanding and cooperation.

Best regards,
[Your Name]

Template 2: Follow-Up (After No Response)

Subject: Follow-Up: Document Fraud Detection — [Document Name/Reference]

Dear [Name],

I am following up on my previous message from [date] regarding the [document type].

The detection process flagged some concerns that I need to resolve before we can proceed. You can review the analysis here: [HTPBE Result Link]

Could you please respond at your earliest convenience? If I do not hear back by [date], I will need to [escalate to your supervisor / delay processing / use alternative fraud detection methods].

Thank you for your prompt attention to this matter.

Best regards,
[Your Name]

Template 3: Escalation (Serious Concerns)

Subject: URGENT: Document Authentication Required — [Document Name/Reference]

Dear [Name/Department],

I am escalating a document fraud detection issue that requires immediate attention.

The [document type] dated [date] has been flagged by htpbe.tech with high-confidence modification indicators. You can view the technical analysis here: [HTPBE Result Link]

Given the nature of this document [describe importance — e.g., “which includes payment instructions for $X”], I need to check its authenticity before proceeding.

Please:

Confirm whether this document was intentionally modified

Provide the original, unmodified version if available

Check the payment/banking details through an independent channel

I am available at [phone number] if you prefer to discuss this directly.

Regards,
[Your Name]
[Your Position]

Best Practices for Document Security

To minimize issues with modified documents in the future:

Always check important documents — make PDF tamper detection part of your standard workflow
Request digitally signed PDFs — signatures provide cryptographic proof of authenticity
Establish fraud detection protocols with regular partners and vendors
Use secure channels for document exchange (encrypted email, secure portals)
Check payment changes through phone calls to known numbers, never through email alone
Keep records of all detection results for audit purposes

When to Involve Security or Legal Teams

Consider escalating to your security, compliance, or legal team if:

The document involves significant financial transactions
Modifications appear to alter critical information (amounts, dates, account numbers, terms)
The sender cannot or will not explain the modifications
You suspect intentional fraud or document tampering
The document is part of a legal or regulatory matter

HTPBE? as Your Neutral Arbiter

If you and the document sender cannot agree on whether a file has been modified, HTPBE? can serve as a neutral third party:

Both parties review the same HTPBE result
Either party can submit a dispute for manual review
Our forensic team provides an independent assessment
The result serves as objective evidence for both sides

This is particularly useful in:

Vendor disputes about invoice authenticity
Contract disagreements about document versions
Insurance claims requiring document fraud detection
Legal matters where document integrity is questioned

Conclusion

Discovering a modified PDF does not automatically mean fraud or wrongdoing. Many modifications are innocent and explainable. The key is approaching the situation professionally:

Share the result — let the other party see what you see
Ask questions — give them a chance to explain
Document everything — keep records of all communication
Escalate when needed — do not proceed with unchecked critical documents
Use the dispute process — let us help when you need a neutral assessment

By following these steps, you protect yourself and your organization while maintaining professional relationships and trust.

How to Detect Tampered PDFs (Forensics Tutorial)

Iurii Rogulia — Wed, 20 May 2026 07:00:25 +0000

A client sends you a signed PDF contract. Looks legitimate. The signature block is there, the date is right, the numbers look fine. But something feels off. How do you know if it's the original or if someone changed a figure on page 3 and re-exported it?

I spent 5 days and 7 algorithm versions figuring this out. The result is HTPBE? — Has This PDF Been Edited? — a SaaS that analyzes a PDF in under 9 seconds and tells you exactly how many times it was modified, by what software, and which forensic markers triggered. Here's how it works.

How a PDF Is Actually Structured

Before talking about tamper detection, you need to understand what a PDF file actually contains at the binary level. It's not magic — it's a structured document format from 1993 that has some remarkably useful forensic properties.

A PDF has four sections:

Header — identifies the PDF version (%PDF-1.7, %PDF-2.0, etc.)
Body — the actual objects: pages, fonts, images, text streams
Cross-reference table (xref table) — an index that maps object numbers to their byte offsets in the file
Trailer — points to the xref table and contains document metadata

The xref table is the key. It's how a PDF reader finds objects quickly without scanning the entire file. And it's where tampering leaves an unmistakable trail.

The Core Insight: Count the xref Tables

When a PDF is created from scratch — by InDesign, Word, a PDF printer, anything — it contains exactly one xref table. That's the baseline.

Now someone opens the file in Adobe Acrobat and changes a number. Acrobat doesn't rewrite the entire file. That would be slow and could corrupt things. Instead, it appends the changes to the end of the file and adds a second xref table pointing to the new and modified objects. The original content is still there, underneath — just superseded.

This is called an incremental update. And it's the foundation of my detection approach:

One xref table = original document. Two or more xref tables = the document was modified after initial creation.

Every editor does this: Adobe Acrobat, Preview on macOS, LibreOffice, Foxit, PDF-XChange. They all append, never rewrite.

There is one legitimate exception, which took me several algorithm versions to handle correctly: LTV (Long-Term Validation) updates. When a digitally signed PDF needs to embed certificate revocation data for long-term validation, the signing software adds an incremental update with OCSP responses and CRL data. This is legitimate, expected, and should not be flagged as tampering. Missing this in v1 of my algorithm caused a flood of false positives on signed legal documents.

The 7 Forensic Markers

Counting xref tables is the primary signal. But a thorough analysis needs multiple corroborating markers. Here are the seven I check in every analysis:

1. xref Table Count

The count of xref or startxref keywords in the binary. More than one means incremental updates exist. I also check whether those updates are LTV-related before flagging them.

2. Incremental Update Signatures

Beyond just counting, I look at the structure of each incremental update: which object types were added or modified. A legitimate signing update touches only certain object types (signature dictionaries, DSS dictionaries). An update that modifies page content objects is a much stronger tampering signal.

3. Producer Metadata Field

Every PDF has a Producer field in its document info dictionary. This is set by whatever software created or last saved the file. A PDF generated by a hospital system might have Producer: Epic Systems. If the Producer field says Adobe Acrobat 23.0 but the document claims to be an original bank statement — that's a mismatch worth investigating.

I also look for multiple Producer strings across different revisions, which indicates the file passed through more than one software tool.

4. Creation Date vs. Modification Date Mismatch

The CreationDate and ModDate fields in PDF metadata. If they differ significantly — especially if ModDate is after CreationDate by years — that's a signal. If CreationDate is missing entirely but ModDate exists, that's unusual. If both are present but identical after an apparent edit, someone tried to cover their tracks.

5. Orphaned Objects

When PDF editors modify or delete content, the original objects often remain in the file — they're just no longer referenced from the active xref table. They become "orphaned" objects: still in the binary, not reachable from the current document tree. I scan for these. Their presence indicates prior revisions, and their content sometimes reveals what was changed.

6. Encryption and Permissions Changes

If a PDF's encryption dictionary changes between revisions, that's notable. It can indicate an attempt to remove password protection, change editing permissions, or re-encrypt content. I compare encryption settings across xref revisions where detectable.

7. Font Embedding Changes

Fonts embedded in a PDF are large objects. Changing text requires access to the right fonts. If a new font appears in a later xref revision that wasn't in the original, and it's not a system font added by a viewer for display purposes, that's a meaningful signal — particularly if the new font covers a character range used in key fields like amounts or dates.

The 7 Algorithm Versions (What Actually Failed)

I'll be honest about the iteration process: it wasn't linear.

v1 was exactly what it sounds like: count occurrences of xref and startxref in the binary, report the number. This produced catastrophic false positives. Signed PDF documents routinely have 2–3 incremental updates from the signing and LTV process. I was flagging every notarized document as tampered.

v2 added a heuristic: if the file contains a digital signature (/Sig object), ignore the first two incremental updates. Better, but wrong. The number of LTV updates is variable — some signing workflows produce one, some produce three.

v3 was the LTV breakthrough: instead of counting incremental updates after signatures, I actually parse the structure of each update to determine if it contains only DSS (Document Security Store) objects and OCSP/CRL data. If so, it's marked as LTV and excluded from the tampering score. This eliminated 90% of false positives on signed documents.

v4 added the Producer field analysis. This is where I discovered that some PDF generators write garbage into the Producer field — truncated strings, encoding artifacts, empty strings — which made simple string matching unreliable. I had to normalize and sanitize the field before comparison.

v5 introduced confidence scoring instead of binary yes/no. A single incremental update by itself is weak evidence. An incremental update plus a Producer field change plus orphaned content objects is strong evidence. Each marker contributes a weighted score to an overall confidence percentage.

v6 broke things. I tried to add binary-level entropy analysis to detect unusual compression patterns. It was interesting but the false positive rate on legitimately compressed PDFs made it useless in practice. I removed it.

v7 is what ships. Confidence scoring, LTV exclusion, seven markers, no entropy analysis.

slug="mvp-development"
text="Need to build document verification, fraud detection, or KYC tooling into your product? I can own this from the forensics layer to the billing and API surface."
/>

Technical Implementation

Parsing with pdf-lib

I use pdf-lib for structural parsing. It handles the xref table and object access well. For raw binary analysis — finding byte offsets, scanning for marker strings — I work directly on the ArrayBuffer.

Here is the core xref analysis:

interface XrefEntry {
  offset: number;
  isLTV: boolean;
  producerField: string | null;
  hasContentChanges: boolean;
}

async function analyzeXrefTables(fileBuffer: ArrayBuffer): Promise<XrefEntry[]> {
  const bytes = new Uint8Array(fileBuffer);
  const text = new TextDecoder("latin1").decode(bytes);
  const entries: XrefEntry[] = [];

  // Find all startxref markers — each one marks an xref table or xref stream
  const startxrefPattern = /startxref\s+(\d+)/g;
  let match: RegExpExecArray | null;

  while ((match = startxrefPattern.exec(text)) !== null) {
    const offset = parseInt(match[1], 10);

    // Skip the terminal startxref before %%EOF — offset 0 is the document terminator
    if (offset === 0) continue;

    const entry = await parseXrefRevision(bytes, text, offset);
    entries.push(entry);
  }

  return entries;
}

async function parseXrefRevision(
  bytes: Uint8Array,
  text: string,
  offset: number
): Promise<XrefEntry> {
  const trailerStart = text.indexOf("trailer", offset);
  const trailerEnd = text.indexOf(">>", trailerStart);
  const trailerContent = trailerStart !== -1 ? text.slice(trailerStart, trailerEnd + 2) : "";

  // DSS (Document Security Store) presence indicates an LTV update
  const hasDSSObject = trailerContent.includes("/DSS");
  const hasOnlySigObjects = checkForSignatureOnlyUpdate(text, offset);

  const producerMatch = /\/Producer\s*\(([^)]+)\)/.exec(text.slice(offset, offset + 4096));
  const producerField = producerMatch ? producerMatch[1].trim() : null;

  const hasContentChanges = checkForContentModifications(text, offset);

  return {
    offset,
    isLTV: hasDSSObject || hasOnlySigObjects,
    producerField,
    hasContentChanges,
  };
}

function checkForContentModifications(text: string, offset: number): boolean {
  // /Contents, /Page, and BT/ET (Begin Text/End Text) operators signal content edits
  const revisionSlice = text.slice(offset, offset + 16384);
  const contentIndicators = ["/Contents", "/Page\n", "/Pages\n", "BT\n", "ET\n"];
  return contentIndicators.some((indicator) => revisionSlice.includes(indicator));
}

function computeTamperingScore(entries: XrefEntry[]): number {
  const nonLTVEntries = entries.filter((e) => !e.isLTV);

  // Base document always has one xref — anything beyond is an edit
  const editCount = Math.max(0, nonLTVEntries.length - 1);
  if (editCount === 0) return 0;

  let score = 0;
  score += Math.min(editCount * 25, 60);

  // Content modifications are a stronger signal than metadata-only changes
  const contentEdits = nonLTVEntries.filter((e) => e.hasContentChanges);
  score += contentEdits.length * 15;

  // Multiple distinct Producer strings across revisions indicate tool switching
  const producers = new Set(nonLTVEntries.map((e) => e.producerField).filter(Boolean));
  if (producers.size > 1) score += 20;

  return Math.min(score, 100);
}

Bypassing Vercel's 4.5MB Serverless Limit

PDF files up to 10MB need to be analyzed. Vercel's serverless functions have a 4.5MB request body limit. Sending a 10MB PDF directly to an API route fails with a 413 — or worse, silently truncates the body.

The solution is Vercel Blob with client-side upload. The browser uploads directly to Vercel Blob storage (bypassing the serverless function entirely via a token endpoint), then passes the blob URL to a Server Action for analysis. The file never flows through the serverless function body at all.

// components/Hero/index.tsx — Step 1: browser → Vercel Blob
import { upload } from "@vercel/blob/client";

const blob = await upload(filename, file, {
  access: "public",
  handleUploadUrl: "/api/blob-token",
  clientPayload: JSON.stringify({ size: file.size }),
});

// Step 2: pass blob URL to Server Action for analysis
await analyzePdf(blob.url, file.name);

// app/api/blob-token/route.ts — origin-based security for token generation
import { handleUpload } from "@vercel/blob/client";

const ALLOWED_ORIGINS = [process.env.NEXT_PUBLIC_APP_URL!];

export async function POST(req: Request): Promise<Response> {
  const origin = req.headers.get("origin") ?? "";
  const isAllowed = ALLOWED_ORIGINS.some((o) => origin === o);
  if (!isAllowed) return new Response("Forbidden", { status: 403 });

  const body = await req.json();
  const jsonResponse = await handleUpload({
    body,
    request: req,
    onBeforeGenerateToken: async () => ({
      allowedContentTypes: ["application/pdf"],
      maximumSizeInBytes: 10 * 1024 * 1024,
    }),
  });
  return Response.json(jsonResponse);
}

Async Processing with Polling

Analysis takes up to 9 seconds. That's too long for a synchronous Vercel function. I use an async pattern: the job is queued, a job ID is returned immediately, the client polls for results.

// app/api/analyze/route.ts — accepts the Vercel Blob URL, returns a job ID immediately
export async function POST(request: Request) {
  const { blobUrl } = await request.json();
  const jobId = crypto.randomUUID();

  await redis.setex(`job:${jobId}`, 600, JSON.stringify({ status: "queued" }));
  await analysisQueue.add("analyze-pdf", { blobUrl, jobId });

  return Response.json({ jobId });
}

// app/api/analyze/[jobId]/route.ts — client polls this until status === "completed"
export async function GET(request: Request, { params }: { params: Promise<{ jobId: string }> }) {
  const { jobId } = await params;
  const raw = await redis.get(`job:${jobId}`);
  if (!raw) {
    return Response.json({ error: "Job not found" }, { status: 404 });
  }
  return Response.json(JSON.parse(raw));
}

The client polls every 1.5 seconds. Most files finish in 3–5 seconds. The 9-second ceiling is for maximum-size PDFs with complex xref structures.

Gotchas Worth Knowing

LTV updates will fool a naive implementation. If you just count xref tables, every notarized PDF, every DocuSign document, every government e-signature will appear tampered. You must parse the update structure and identify LTV-specific object types before flagging anything.

base64-encoded PDFs need special handling. Some APIs transmit PDFs as base64 strings. If you run binary analysis on the raw base64 string without decoding first, your byte-offset calculations will be completely wrong. Decode to Uint8Array before any binary analysis.

File size from binary vs. encoded differs by ~33%. The File API's .size property returns the correct binary byte count. The .length of a base64 string is approximately 33% larger. Keep this straight or your 10MB validation will reject valid files.

The terminal startxref before %%EOF has offset 0. This is the document terminator marker, not a real xref table. Naive regex counting includes it and inflates the xref count by one. Filter out any entry where offset === 0.

Some enterprise PDF generators produce split xref tables in the original document. Certain systems write multiple xref sections at creation time (not incremental updates). I handle this by checking whether all xref sections share the same Producer metadata — if they do and there are no trailer Prev pointers, it's a single logical revision.

Results

Analysis time: under 9 seconds for files up to 10MB
False positive rate on legitimately signed documents: near zero after v3 LTV handling
Detection coverage: 100% for the 7 deterministic markers
File size limit: 10MB, handled via presigned S3 uploads to bypass serverless body limits

The confidence scoring approach handles ambiguous cases better than a binary flag would. A document with one extra xref table from a PDF optimizer (score: 25, low confidence) is treated very differently from a document with three non-LTV incremental updates, two different Producer strings, and orphaned content objects (score: 85+, high confidence). Users get actionable context, not just an alarm.

Try it at HTPBE?. Upload any PDF — a bank statement, a contract, a signed invoice — and see the full forensic breakdown.

If you're building fintech or legaltech tooling where document authenticity matters — loan origination, contract management, insurance claims, KYC workflows — this kind of verification layer is worth integrating directly into your pipeline. The seven markers described here are implementable in any language with binary file access.

If you need a senior developer who can build document verification systems, automation pipelines, or SaaS infrastructure from scratch — get in touch. I'm available for freelance projects and long-term engagements.

Related reading: Technical SEO I Build Into Every Project — because the same "build it right the first time" discipline applies to indexing infrastructure too. | One Package, Five Registries — another example of shipping multiple layers of a system end-to-end.

Understanding PDF Metadata: What Your Documents Reveal

Iurii Rogulia — Tue, 19 May 2026 10:00:27 +0000

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.

Every PDF document contains hidden information called metadata — data about the document itself rather than its visible content. This metadata reveals how the document was created, when it was modified, which applications processed it, and much more.

Most users never see this information, but it is always there, embedded in every PDF file. Understanding PDF metadata helps you check document authenticity, protect privacy, and detect modifications.

This article explains what PDF metadata is, what information it contains, how to view it, what it reveals about documents, and how it is used in document fraud detection.

The Hidden Data in Every PDF

PDF metadata is like a document’s “birth certificate” — it records the document’s creation and processing history. This information is embedded in the PDF file structure and can be accessed by anyone who knows how to view it.

As Adobe explains, metadata provides valuable information about document origin and history, but it can also raise privacy concerns if sensitive information is included.

What Is Metadata?

Metadata is “data about data” — information that describes other information. In PDFs, metadata describes the document itself:

Who created it: Author and creator application
When it was created: Creation and modification dates
What it is: Title, subject, keywords
How it was processed: Producer application, PDF version
Technical details: File size, page count, encryption status

Unlike the visible content of a PDF (text, images, layout), metadata is embedded in the file structure and requires special tools to view.

Types of PDF Metadata

PDF metadata includes several categories of information:

Standard Fields

Basic document information:

Title: Document title
Author: Person or organization that created the document
Subject: Document subject or description
Keywords: Searchable keywords for document classification

Purpose: These fields help organize and search documents, but they are often left blank or contain default values.

Creation and Modification Dates

Temporal information:

Creation Date: When the PDF was first created
Modification Date: When the PDF was last modified

What it reveals:

Document age and history
Modification timeline
Potential tampering indicators
Processing chronology

Important: These dates can be manipulated, so they are not always reliable indicators of authenticity.

Creator Application

Source information:

Creator: Application that originally created the PDF
Producer: Software that last processed the PDF

What it reveals:

Document origin (Word, Excel, Photoshop, etc.)
Processing history
Editing tool usage
Application fingerprints

Example: A document created in “Microsoft Word” but produced by “Adobe Acrobat Pro” suggests the document was edited after creation.

Producer Information

Processing details:

Producer: Software that last processed the PDF
PDF Version: PDF specification version used
Encryption: Encryption status and method

What it reveals:

Last processing application
PDF specification compliance
Security settings
Technical capabilities used

As Pics.io explains, producer information can reveal editing history even when other indicators are hidden.

Where Metadata Comes From

Understanding metadata sources helps interpret the information:

Application-Generated Metadata

Automatic creation:

Applications automatically populate metadata
Uses information from source documents
Includes application identification
Records processing timestamps

Common sources:

Microsoft Office applications (Word, Excel, PowerPoint)
Adobe applications (Acrobat, Photoshop, Illustrator)
Online PDF converters
PDF editing tools

User-Provided Metadata

Manual entry:

Users can manually enter metadata
Often left blank or with defaults
May contain sensitive information
Can be intentionally misleading

Privacy concern: Users may inadvertently include sensitive information in metadata fields.

Processing Metadata

Tool-generated:

PDF processing tools add metadata
Records processing history
Includes tool identification
Tracks modification history

Forensic value: Processing metadata can reveal document editing history.

As Allyant notes, metadata accumulates as documents are processed by different tools.

How to View PDF Metadata

Viewing metadata is straightforward:

Adobe Acrobat Reader

Steps:

Open the PDF file
Right-click and select “Properties” (or File → Properties)
Review metadata in the “Description” tab
Check the “Advanced” tab for additional technical details

Information displayed:

Title, Author, Subject, Keywords
Creation and Modification dates
Creator and Producer applications
PDF version and security settings

Free Online Tools

Web-based viewers:

Upload PDF to online metadata viewer
View metadata without installing software
Access from any device
No software installation required

HTPBE? provides free metadata analysis along with modification detection — upload your PDF at htpbe.tech for instant results without signup.

Privacy note: Be cautious uploading sensitive documents to online tools. HTPBE? does not store your files after analysis.

Operating System Methods

Windows:

Right-click PDF file
Select “Properties”
Check the “Details” tab for metadata

macOS:

Right-click PDF file
Select “Get Info”
Review metadata in the info window

Limitations: Operating system methods show limited metadata compared to PDF-specific tools.

As Adobe explains, different tools show different levels of metadata detail.

What Metadata Reveals About a Document

Metadata provides insights into document history and authenticity:

Document Origin

Creation source:

Which application created the document
When document was created
Who created it (if author field populated)
Original document type (Word, Excel, etc.)

Use case: Checking document origin matches expected source.

Processing History

Modification timeline:

When document was modified
Which applications processed it
Processing sequence
Modification frequency

Use case: Detecting unauthorized modifications or editing history.

Application Fingerprints

Tool identification:

Creator application signatures
Producer application patterns
Version information
Tool-specific metadata

Use case: Identifying editing tools used, detecting unexpected applications.

Technical Details

File characteristics:

PDF version used
Encryption status
File size
Page count
Security settings

Use case: Understanding document technical properties and capabilities.

As pypdf documentation explains, metadata analysis provides forensic insights into document processing.

Privacy Concerns: What You Might Be Sharing

Metadata can contain sensitive information:

Personal Information

Potential exposure:

Author names (may reveal document creator)
Company names (may reveal organization)
Email addresses (if included in metadata)
User names (from application settings)

Risk: Metadata travels with PDF files and can be viewed by anyone who receives the document.

Document History

Revealed information:

Creation dates (may reveal document age)
Modification dates (may reveal editing history)
Application names (may reveal software used)
File paths (may reveal directory structure)

Risk: Document history can reveal sensitive information about document processing.

Organizational Information

Exposed details:

Company names in author fields
Department information
Project names in titles
Internal file naming conventions

Risk: Organizational information in metadata can be valuable to competitors or attackers.

Best Practices for Privacy

Protect metadata:

Remove sensitive metadata before sharing
Use metadata cleaning tools
Avoid including personal information
Review metadata before distribution

As 4n6k forensics notes, metadata forensics can reveal more than intended, making privacy protection important.

How to Edit or Remove Metadata

You can edit or remove metadata to protect privacy:

Adobe Acrobat

Steps:

Open PDF in Adobe Acrobat
Go to File → Properties
Edit metadata fields in the Description tab
Click “OK” to save changes

Limitations: Some metadata (like creation date) may not be editable in all versions.

Metadata Cleaning Tools

Specialized tools:

PDF metadata editors
Privacy-focused PDF tools
Command-line utilities
Online metadata cleaners

Features:

Remove all metadata
Edit specific fields
Batch processing
Privacy protection

Best Practices

Before sharing:

Review metadata for sensitive information
Remove unnecessary metadata
Edit author fields if needed
Clean metadata for public distribution

Privacy protection:

Remove personal information
Clean company-specific data
Remove file paths
Sanitize before sharing

Metadata in Document Fraud Detection

Metadata plays a crucial role in PDF tamper detection. Tools like HTPBE? analyze metadata patterns to detect document modifications automatically:

Modification Detection

How it works:

Compare creation and modification dates
Check for unexpected date patterns
Identify suspicious modifications
Detect timeline anomalies

Use case: Identifying documents modified after creation or signing.

Application Fingerprinting

Tool identification:

Identify creator and producer applications
Detect unexpected editing tools
Match application patterns
Identify tool-specific signatures

Use case: Detecting documents edited with unexpected applications.

Timeline Analysis

Chronological fraud detection:

Compare dates with expected timeline
Check modification sequence
Check for date inconsistencies
Validate processing order

Use case: Checking document processing matches expected workflow.

Cross-Reference Analysis

Metadata consistency:

Compare metadata with document content
Check for metadata inconsistencies
Validate application claims
Detect metadata manipulation

Use case: Identifying metadata that has been manipulated to hide modifications.

Can Metadata Be Faked or Removed?

Yes — metadata can be edited or stripped from PDF files using various tools. However, manipulation is harder to hide than it appears:

Editing metadata leaves traces: Changing timestamps or creator fields introduces structural inconsistencies that forensic analysis can detect
Missing metadata is suspicious: PDFs generated by professional software always include metadata. A document with no creation date, no creator, and no producer is unusual and warrants scrutiny
Inconsistent patterns: Metadata that does not match the claimed source (a bank statement with a generic consumer PDF editor as the creator, for example) is a red flag even if individual fields look plausible

This is why HTPBE? does not rely on metadata alone. Multi-layer analysis combines metadata inspection with internal structure examination, signature fraud detection, and pattern matching against known fraud signatures. Metadata is the starting point, not the final word.

How HTPBE? Uses Metadata: The 5-Layer Process

When you upload a PDF to HTPBE?, metadata analysis is the first of five fraud detection layers:

Extract all metadata fields: Creation date, modification date, creator, producer, PDF version, and all available properties
Check for date inconsistencies: Does the modification date precede the creation date? Is the creation date in the future relative to the upload time? Do timestamps align with the document’s claimed origin?
Analyze creator and producer patterns: Do the applications match the expected source? Are there signs of editing tools that should not appear in this workflow?
Examine internal PDF structure: Cross-reference metadata claims against the actual file structure — incremental updates, xref tables, object modifications
Compare against known fraud signatures: Match patterns against a database of known modification techniques and fraud indicators

The result combines all signals into a single verdict: Intact, Modified, or Cannot Verify.

Conclusion

PDF metadata is embedded information that reveals document creation and processing history. Understanding metadata helps you:

Check authenticity: Check document origin and modification history
Detect modifications: Identify unauthorized changes
Protect privacy: Remove sensitive information before sharing
Understand documents: Learn about document processing and tools used

Metadata is a powerful tool for document fraud detection, but it can also raise privacy concerns. Review metadata before sharing documents, and use metadata analysis as part of comprehensive PDF tamper detection.