Most comparison pages in this category are feature tables where the host wins every row. This one can't be, because the two products aren't the same shape and a table would hide that rather than show it.
Here is the whole difference, and everything else follows from it.
DocRaptor takes HTML at request time. You POST
document_content — or a document_url and it
fetches the page — and Prince renders it. Your template lives in your
repo, next to the code that fills it.
iReceipt PRO takes a template id and JSON.
POST /v1/pdf/private/{templateId} with
{"variables": {...}}, and the file comes back. There is no
raw-HTML endpoint. The layout lives on our side, authored in the
dashboard.
So the question isn't which renders better. It's where your layout is allowed to live.
The question that actually decides it
Does the layout need to be versioned with the code that fills it?
If yes — if a change to the invoice template has to ship in the same pull request as the change to the invoice model, get reviewed by the same person, and roll back together — then a hosted template is a downgrade and you should stop reading here. DocRaptor fits that workflow and we don't. That isn't a limitation we're planning to remove. It's the design.
If no — if the layout changes on a different rhythm from the code, usually because a designer or an ops person owns how the receipt looks and an engineer owns what goes on it — then getting the template out of the repo is the point rather than a compromise. That's the case we're built for.
Where DocRaptor is straightforwardly better
Three places, and they're not close.
Typeset documents
DocRaptor runs Prince, and it exposes CSS Paged Media properly: running headers and footers, page counters, footnotes and sidenotes, cross-references, named strings, leaders, generated tables of contents, PDF bookmarks, named pages, page floats, CMYK, duplex properties (their feature list, read 2026-08-17). If you're producing a 200-page report where a footnote has to sit on the page that references it and the table of contents has to build itself, that is Prince's job and nothing browser-based does it as well. We don't compete for this and shouldn't.
Spreadsheet output
DocRaptor emits PDF, XLS and XLSX (docs, read 2026-08-17). We don't do spreadsheets at all. If half your outputs are workbooks, that's the end of the evaluation.
A published compliance posture
This one's uncomfortable to write and it belongs here anyway. DocRaptor's security page states SOC 2 Type II, full GDPR compliance with a DPA available, participation in the EU–U.S. Data Privacy Framework including the UK and Swiss extensions, HIPAA on all paid plans at no extra charge with a BAA, AES-256 at rest and TLS in transit, annual third-party penetration tests, and a configurable document retention setting (security and privacy, re-read 2026-11-04).
Four answers in their security FAQ are worth knowing because they close questions a procurement team will ask:
-
Region. Rendering runs on AWS
us-east-1, and they say so in as many words: all processing is performed in the United States. - Retention, in detail. Configurable per account from "as short as possible" up to seven days. At the shortest setting input is deleted as it's consumed and output is deleted on download, or after fifteen minutes if nobody downloads it.
- Logs and training. Logs carry metadata only, never document content, and they say they do not currently use document content for model training.
- Sub-processors. Published as a list, with email notification when it changes.
They also publish a 99.99% uptime guarantee (their page, read 2026-11-04).
We don't publish an uptime figure, and the thing we do publish is worth being precise about rather than borrowing credit from. status.ireceipt.pro exists and is live, but read what it says it is: "live availability of the iReceipt PRO API, checked directly from your browser". It tells you whether the API answers right now. It isn't a history, there's no percentage on it, and nothing on our side commits to one. If your procurement process wants a number in a contract, theirs has one and ours does not.
And the company has changed hands. Their own security FAQ says the contracting entity and data processor is DocRaptor, LLC, an Indiana limited liability company, and that "following Artifex Software, Inc.'s acquisition of DocRaptor, DocRaptor is now part of the Artifex Software group". Artifex are the Ghostscript and MuPDF people. Draw your own conclusion about what that means for the roadmap; I don't have one worth printing. But if you're signing a multi-year agreement it's a fact you want before the lawyers find it, and it isn't on their homepage.
We haven't published an equivalent to any of this, with one exception. On retention we do have a page, and it says something stronger than any configurable window. Our privacy policy (privacy policy) states that we "do not collect or store information received by the API during the use of the service" — there is nothing on our servers to erase, at any setting.
The rest of that list stands against us, and the gap got wider rather than narrower in the eleven weeks between the two readings of their page. No SOC 2, no DPA, no Data Privacy Framework participation, no HIPAA or BAA, no stated region, no published sub-processor list, no uptime commitment and no uptime history, and governing law in Georgia with a $100 liability cap. If your evaluation has a security review in it and it's happening this month, they can answer it today and we can't. That's a real difference and you should weigh it as one.
Where we're different, rather than better
Images, not just documents
We return PDF, JPG, PNG and WEBP from the same template mechanism. The
SDK is eight methods, being four formats times two template scopes —
create{Pdf,Jpg,Png,Webp}From{Public,Private}Template. If
you're generating an invoice PDF and a social preview image
and a QR-coded voucher, that's one vendor and one template system
instead of a PDF API plus an image API. If you only ever need PDFs, this
buys you nothing.
The template stops being a deployment
Changing the header on a receipt doesn't touch your repo, your CI, or your release. Whether that reads as a feature or as a loss of control is exactly the question from two sections up.
Less rope
No javascript: true flag to reason about, no base-URL trick
for relative asset paths, no decision about screen versus print
stylesheets. Fewer knobs is worse when you need the knobs.
The calls, side by side
DocRaptor, HTTP basic auth with the key as the username:
POST https://api.docraptor.com/docs
{
"type": "pdf",
"document_content": "<html>…the invoice you just rendered…</html>",
"javascript": true
}Ours, bearer token, template id in the path:
POST https://api.ireceipt.pro/v1/pdf/private/invoice_abc123
Authorization: Bearer <api key>
{ "variables": { "customer": "Acme GmbH", "total": "1240.00" } }Two things about ours that are easy to miss and will cost you twenty minutes if you don't know them. The first is in the API reference and on the errors page; the second is only in the SDK's source.
Success is 201, not 200. Check for the wrong code and every render looks like a failure.
And createFile makes five attempts, not five
retries. It only re-tries failures a retry could fix: transport
errors where no response came back at all, anything 5xx, and the two 4xx
codes that invite one (408 and 429). A rejected request — wrong key,
unknown template, a size your plan doesn't allow — throws on the first attempt instead,
which is the behaviour you want.
The sleeps between attempts grow by a second each round: 2 + 3 + 4 + 5 =
fourteen seconds of waiting. Be careful what you conclude
from that number, because it is the part that is easy to get wrong:
it is the sleep time only, and it is a floor rather than a worst
case. The SDK passes no timeout to axios, so axios's
default applies and each of the five attempts is unbounded. A full ladder
therefore costs fourteen seconds plus however long five attempts
take. If you wrap the call in your own deadline, size it against that —
and if what you want is a bounded call, set the timeout yourself rather
than inferring one from the backoff.
The retry behaviour is read from dist/esm/methods/createFile.js in the
published @ireceipt.pro/js 2.0.65 tarball, on 2026-11-04.
Note the argument name too: the SDK calls it args, the wire
format calls it variables.
Pricing, and why there's only half a comparison here
DocRaptor publishes theirs: a free tier limited to 5 document conversions a month, unlimited test documents with a watermark on them, and paid plans starting at $15/month (their page, re-read 2026-11-04 — all three figures unchanged since August). They also say they don't charge extra for large documents or pages, and that there are no input or output size limits.
Ours are live in the dashboard and aren't written down anywhere I can cite, so I'm not going to put a number on this page and have you find out it was wrong. Sign in at dashboard.ireceipt.pro and the current tiers are there. If a page that compares two products declines to compare the prices, that's worth knowing about the page. I'd rather flag it than fudge it.
Pick DocRaptor if
- Your templates are in your repo and have to stay there
- You need real paged-media typesetting — footnotes, cross-references, a generated table of contents
- Anything you produce is XLS or XLSX
- You're passing a security review this quarter and need SOC 2 and a DPA now
- The HTML is composed per request and genuinely varies in structure, not just in values
Pick us if
- Layout is stable and the data changes every time. Invoices, receipts, tickets, certificates, gift cards, labels
- You need images out of the same system as the documents
- Whoever owns how it looks isn't the person who owns the deploy
- You'd rather not have HTML-in-a-JSON-body anywhere in your codebase
Pick neither if
Volume is a handful of documents a day. At that scale Puppeteer and a cron job is genuinely fine and both of us are overhead. There's a longer version of that argument on this site: running Puppeteer yourself, or calling an API, including the part where self-hosting wins.
Also skip both if you need rendering fully offline or air-gapped, if the documents are interactive rather than printed, or if what you actually want is a document editor rather than a rendering API.