Per-page vs per-document PDF API pricing: which costs less?

Two different units of billing

A PDF generation API has to charge for something, and vendors split into two camps. Per-page pricing charges a small amount for every page rendered — a 1-page receipt costs less than a 40-page report. Per-document pricing charges a flat amount per successful render, regardless of whether that render produced 1 page or 100. Docweave uses the second model: one charge per document, not per page.

Neither model is a scam and neither is universally better — they just allocate risk differently. Per-page pricing rewards you for keeping documents short. Per-document pricing rewards you for not knowing (or not controlling) how long a document will be.

Worked example: 2,000 documents a month, 3 pages each

Say a per-page vendor charges an illustrative $0.01 per page, and a per-document vendor charges an illustrative $0.05 per document (always check current numbers on pricing and run your own volume through the PDF cost calculator — these are round numbers for the math, not a quote).

2,000 docs/month, average 3 pages each

Per-page:     2,000 × 3 pages × $0.01/page = $60/month
Per-document: 2,000 docs × $0.05/doc       = $100/month

→ Per-page is cheaper here. At 3 pages/doc, you're below the crossover.

Now change only the average page count. If those same 2,000 documents are actually reports averaging 12 pages because they embed tables and charts:

2,000 docs/month, average 12 pages each

Per-page:     2,000 × 12 pages × $0.01/page = $240/month
Per-document: 2,000 docs × $0.05/doc         = $100/month

→ Per-document is now 2.4x cheaper.

The crossover is just rate division: $0.05 ÷ $0.01 = 5 pages. Below 5 pages/document on average, per-page wins. Above 5, per-document wins. That ratio — not vague vendor marketing — is the actual thing to check against your own documents.

Where per-page pricing genuinely wins

If your volume is low and your documents are consistently short, per-page pricing can be the cheaper and simpler choice. Single-page receipts and certificates are the clearest case — they rarely grow past one page, so you're never paying for pages you don't need. If that's 100% of your workload, it's fair to say per-page pricing will usually beat a flat per-document fee, and we're not going to pretend otherwise.

Where per-document pricing wins

Per-document pricing wins whenever page count is either high on average or unpredictable per request. Invoices are the textbook case: an invoice with 3 line items is 1 page, but the same template with 60 line items might be 4 pages. Contracts and quotes swing even more depending on which clauses or SKUs get included. With per-page billing, your monthly bill becomes a function of your customers' behavior, not your own usage — which makes it hard to forecast and easy to get surprised by.

Per-document billing removes that variable entirely. A 1-page receipt and a 40-page compliance report cost the same to generate, which means your bill scales with request volume — a number you actually control — instead of with content, a number you usually don't.

What "one document" means technically

Under a per-document model, the billable unit is one successful render, however it's triggered. A REST call and an MCP call both count as one document if they succeed once:

curl -X POST https://docweave.dev/api/v1/pdf \
  -H "Authorization: Bearer dw_live_your_key" \
  -H "Content-Type: application/json" \
  -H "Accept: application/pdf" \
  -d '{
    "source": { "type": "html", "html": "<h1>Q2 Report</h1><p>...</p>" },
    "idempotencyKey": "report-2026-q2-acme"
  }' \
  --output report.pdf

await generate_pdf({
  source: { type: "url", url: "https://example.com/invoice/1234" },
  outputPath: "./invoice-1234.pdf",
});

The idempotencyKey matters for the pricing model too: if a retry hits the API after a timeout, Docweave recognizes the key and returns the already-rendered document instead of billing a second document. Under per-page pricing, a naive retry policy can silently double your page count for the month; under per-document pricing, the failure mode is capped at one extra document, not one extra document times its page count.

How to run your own numbers

Don't take either vendor's marketing at face value — pull your last month of generated PDFs, get the average page count per document type, and run both formulas. If you generate a mix of document types (short quotes and long reports, say), do the math per type rather than as one blended average, since the crossover point is different for each. The cost calculator does this arithmetic for you if you'd rather not build a spreadsheet, and the docs cover the request shape either pricing model uses under the hood.

The honest takeaway

There's no universally cheaper model — there's a crossover page count, and which side of it you're on depends on your actual documents. What per-document pricing buys you beyond raw cost, though, is predictability: your bill tracks request volume, a number you set, instead of page count, a number your data usually sets for you.