Skip to main content
Blink PDF offers four plans, from your first proof-of-concept to millions of documents per month. Every plan ships with the same core rendering quality — the same Markdown engine, PDF/UA-1 accessibility, bundled fonts, and 15 curated themes. The only differences are volume, throughput, the free-tier watermark, and support tier.

​
How Billing Works: Render Units

Usage is metered in units, not raw request count. Fill and render draw from the same allowance — not a second meter.
  • A successful fill (POST /v1/fill or MCP fill_form) costs 1 unit.
  • A text-only Markdown render costs 1 unit.
  • Image-heavy renders cost more, up to a hard ceiling of 16 units per render:
  • Images with the same content hash within a render are counted once.
A 402 spend_cap_reached names units, not renders. A maxed key 402s on fill the same way it 402s on render. A single image larger than 24 megapixels, or more than 48 megapixels of images in one render, is rejected with 422 image_too_large before decoding.

​
Plans at a Glance

Body is plan bodyBytes: the cap on a Markdown render and on fill-by-bytes (JSON or multipart pdf). Stored-template size is a different cap — see Stored templates. Annual billing is 10 months prepaid — roughly 17% off (about two months free) compared to paying month-to-month.

​
Plan Details

Free

$0 / month
  • 250 units per month (fill and render share this)
  • “Made with Blink PDF” watermark on every PDF
  • Full theme catalog and typography
  • Community support
  • 10 requests / min, 1 concurrent
  • 128 KiB render / fill-by-bytes body
  • 10 stored templates · 5 MiB upload
  • Fill a real form by storing it, then fill by id

Pro

**9/month∗∗⋅or9 / month** · or 90 / year (~17% off)
  • 30,000 units per month (fill and render share this)
  • $0.004 per extra unit
  • No watermark
  • Per-key usage attribution
  • 120 requests / min, 10 concurrent
  • 2 MiB render / fill-by-bytes body · configurable spend cap
  • 50 stored templates · 10 MiB upload

Business

**79/month∗∗⋅or79 / month** · or 790 / year (~17% off)
  • 1,000,000 units per month (fill and render share this)
  • $0.001 per extra unit
  • No watermark
  • Slack support channel
  • 600 requests / min, 40 concurrent
  • 5 MiB render / fill-by-bytes body · configurable spend cap
  • 250 stored templates · 20 MiB upload

Enterprise

Custom pricing
  • Dedicated capacity, no per-render metering
  • Custom rate limits and uptime commitments
  • Custom templates and branding
  • Can raise the stored-template byte cap
  • On-premise / VPC deployment
  • Contact us

​
Included in Every Plan

No matter which plan you choose, every Blink PDF render includes:
  • Markdown rendering — clean, spec-compliant conversion from Markdown to PDF
  • PDF/UA-1 accessibility — documents pass screen-reader and assistive-technology checks out of the box
  • 15 curated themes — the full theme catalog is identical on every plan
  • Bundled fonts + Google Fonts — six hosted font families plus any Google Fonts family by URL
  • Color emoji (COLR/CPAL) — full-color emoji rendered crisply at any size
  • ToUnicode mapping — text in your PDFs is always copy-pasteable and searchable
  • Font subsetting — only the glyphs you actually use are embedded, keeping file sizes small
  • Input never stored — your Markdown is processed in memory and discarded. REST returns the PDF on the response. MCP download files default to 24 hours; you can opt in to keep them (caps below). See Zero Retention.

​
How Usage Counting Works

Only successful fills and renders consume units. Failed requests, validation calls, and retries that end in an error do not consume units. The authoritative per-response signal is the X-BlinkPDF-Billing header.
Every successful POST /v1/fill, POST /v1/render, or POST /v1/templates/*/render reports its billing outcome in X-BlinkPDF-Billing:
  • counted — the call was billed against your period’s units. A fill is always 1 unit. Sandwich template routes always bill 1 unit when counted.
  • deduped-cache — an identical render was replayed from cache and not billed (POST /v1/render only; fill and sandwich templates do not use the process-local PDF LRU).
  • deduped-idempotent — a reused x-idempotency-key suppressed the charge (POST /v1/render and POST /v1/fill; sandwich templates do not accept client idempotency keys).
Fill and sandwich template routes share the same spend-cap, tier rate/concurrency, usage ledger, and free-tier watermark path as POST /v1/render. Fill is 1 unit on that ledger — not a second meter. The following calls are always free and never consume units:
  • GET /health and other health checks
  • POST /v1/render/validate (dry-run validation — though it has its own rate limit)
  • POST /v1/inspect and POST /v1/validate-fill
  • Storing, listing, getting, updating, or deleting a blank template (POST /v1/templates and the rest of that library)
  • Font, theme, and style-target catalog listings
  • MCP persist_pdf, list_pdfs, delete_pdf, store_template, list_templates, get_template, update_template, and delete_template (keeping a file or a blank is not a fill or a render)

​
Stored PDFs (MCP)

The MCP server can keep a rendered or filled PDF after the 24-hour default. persist: true on render_pdf or fill_form, or persist_pdf while the 24-hour file is still live. Object count only — there is no byte cap. Hitting the cap returns persistent_pdf_limit and does not store the file as 24-hour. Signed download links still expire in 24 hours on every durability. Call list_pdfs for a fresh URL. delete_pdf frees a slot. Stored blank templates do not use these slots — they have their own object cap.

​
Stored templates

A stored template is a blank AcroForm you keep on the account (POST /v1/templates or MCP store_template), then fill by id. It is not a filled output and it is not a Markdown render body. Object count is independent of kept MCP PDFs. Hitting one cap does not block the other. A full object cap returns 409 template_limit. Oversize store or replace is 413 payload_too_large and names maxTemplateBytes. A 20 MiB form is that Business upload cap — a named limit, not a mystery 413. A form over 20 MiB is 413 on every self-service tier. Fill-by-bytes (JSON or multipart pdf on POST /v1/fill) still uses render bodyBytes: 128 KiB / 2 MiB / 5 MiB. That 413 names bodyBytes. Fill-by-id does not re-check the stored PDF against bodyBytes.
On Free, a real form does not fit in the 128 KiB fill-by-bytes body. Store the blank (up to 5 MiB), then send { templateId, values }. The same bytes as a Free fill-by-bytes body are 413.
Inspect and validate-fill do not spend a unit and do not apply bodyBytes to live pdf bytes. Store and replace do not spend a unit.

​
Overage & Spending Caps

Once you pass your plan’s included units, additional units are billed at the per-unit overage rate through Stripe metered billing. Overage is soft — you are never abruptly cut off, and you are never surprise-charged. Each paid tier also has a hard cap at 2× its included volume (60,000 units for Pro, 2,000,000 for Business). Reaching the hard cap returns 402 spend_cap_reached and pauses billing until the next period.
On Pro and Business plans you can set a configurable monthly spending cap below the hard cap. When you hit it, the API returns a clear 402 error rather than continuing to bill — useful for keeping side projects and internal tools within a fixed budget.

​
Annual Billing

Choosing annual billing prepays 10 months for a full year of allowance — roughly 17% savings (~2 months free) versus monthly. The annual base is charged upfront as a single payment; your monthly unit allowance rolls each period. Any overage beyond your included units is still invoiced monthly as you use it.

​
Ready to Get Started?

Create your free account

Sign up in seconds — no credit card required for the Free plan.

Talk to Enterprise sales

Need dedicated capacity, higher limits, or on-premise deployment? We’d love to hear from you.