HTML to Image API Pricing: HTML CSS to Image, Bannerbear and Placid Rates Compared

Every vendor here renders HTML in a headless browser. Four of the five will also hand you a PDF instead of a PNG, because once a browser has painted the page, printing it is close to free. What differs, wildly, is how many credits that costs.

• html2img.com is explicit and flat: "A PDF render costs one credit, exactly the same as a PNG, on every plan including the free tier."
• Abyssale is explicit and flat too, listing "PDF web" alongside JPG and PNG at 1 credit per asset.
• Placid is explicit and not flat: "1 PDF page requires 2 credits." Per page, not per document.
• Bannerbear tells you the direction and withholds the size: "Other types of media such as PDFs and videos use more credits." How many more is not on the pricing page.
• HTML/CSS to Image accepts "png", "jpg", "webp", or "pdf" as output formats in its API documentation, and says nothing anywhere about whether a PDF consumes one image from your allowance or several.

For a single social card this is a footnote. For anything document shaped it is the entire bill. Take the same 10,000 renders a month and make each one a four page PDF, an invoice with a couple of line item pages, or a two sided certificate pack, or a short report:

• html2img.com: 10,000 credits. Still $60.
• Abyssale: 10,000 credits. Still $110.50.
• Placid: 2 credits a page times 4 pages is 8 credits a document, so 80,000 credits a month. The 25,000 plan no longer covers it and you buy the 100,000 plan. $89 becomes $249, a 2.8x jump from a change that cost the other two vendors nothing.
• Bannerbear and HTML/CSS to Image: unbudgetable from published information. You would have to run a test month and read the invoice.

Note what did not happen. The vendor ordering by headline price was html2img, HTML/CSS to Image, Placid, Abyssale, Bannerbear. After one change to the output format, two of those five positions are no longer computable at all. If PDFs are anywhere in your roadmap, the multiplier is the first question to ask, before the price.

HTML/CSS to Image is the only vendor in this group that publishes an overage rate at all, which is a point in its favour. It publishes two of them, and the relationship between them and the plan prices is worth a minute with a calculator.

The standard overage is "Optional ($10/1,000)", which is $0.01 an image. On the Scale plans a second block appears, "$50/10,000", which is $0.005 an image, exactly half the smaller block. Same vendor, same page, two published overage prices a factor of two apart, and which one you get depends on which plan you are already on.

Now compare the $0.01 overage against the in plan rates:

• Entry, $14 for 1,000, is $0.014 an image. The overage rate is 29 percent cheaper than the cheapest plan on the ladder.
• $69 for 10,000 is $0.0069. Overage now costs 1.45x the in plan rate.
• $375 for 100,000 is $0.00375. Overage costs 2.7x.
• $3,000 for 1,000,000 is $0.0030. Overage costs 3.3x.

So overage is a bargain at the bottom of the ladder and a penalty at the top, and the penalty grows the more you spend. That is the same shape we found in document conversion API pricing, where one vendor charges a flat overage that costs 7.1 times its in plan rate on the largest plan and 1.4 times on the smallest. It seems to be a habit of the category rather than one vendor's quirk. The practical rule: buy headroom in proportion to how far up the ladder you are.

Put the two raw HTML rendering ladders next to each other and something obvious falls out. The volume rungs are not merely similar, they are identical: 1,000, 3,000, 10,000, 30,000, 65,000 and 100,000. That is not a natural set of round numbers. A 65,000 rung is nobody's independent invention.

• 1,000: $9 against $14, 36 percent cheaper
• 3,000: $25 against $29, 14 percent cheaper
• 10,000: $60 against $69, 13 percent cheaper
• 30,000: $120 against $149, 19 percent cheaper
• 65,000: $225 against $249, 10 percent cheaper
• 100,000: $300 against $375, 20 percent cheaper

html2img.com has copied the incumbent's ladder and priced under it at every rung, by between 10 and 36 percent, with the deepest cut at the entry point where a buyer is most likely to be comparing. That is a deliberate and perfectly legitimate strategy, and for a price led buyer it is straightforwardly the better deal on these two ladders.

The asymmetry to weigh against it is the ceiling. HTML/CSS to Image publishes rungs up to 1,000,000 images a month at $3,000, where html2img.com's published ladder stops at 100,000. If your volume is heading past a hundred thousand renders a month, one of these two has a published price for you and the other does not.

Abyssale is in every roundup of this category, and on a pure cost per render basis it looks poor. That reading misses what it is. Abyssale charges per seat, at $12, $36 and $60 a seat a month, and its largest published plan carries 750 generation credits.

Set that next to the ceilings on the other ladders. HTML/CSS to Image publishes a rung at a million images a month. Placid publishes 100,000. Bannerbear publishes 50,000. Abyssale's top published plan is 750, which is roughly 1,300 times smaller than the largest rung in the group. You can climb past it with add-on credits at "$0.01 per credit", and to their credit those credits "never expire", but $0.01 is 67 percent above Bannerbear's in plan rate at 10,000 and nearly double html2img.com's.

Which tells you who it is sold to. A per seat price with a small credit allowance and a large AI credit allowance on top (150, 450 and 1500 AI credits by tier) is a brand and marketing team product: a handful of designers producing a controlled number of on brand assets. It is not a volume rendering API and it does not price like one. If you arrived at this page because an application you are building needs to emit images or documents programmatically, Abyssale is probably not your shortlist, and that is a statement about fit rather than quality.

One line on Bannerbear's pricing page has no equivalent anywhere else in this comparison. Alongside the API credit allowance, each plan carries a bandwidth ceiling: 10 GB on Automate, 50 GB on Scale and 100 GB on Enterprise.

That is a second meter, and it binds independently of the first. On Scale you get 10,000 credits and 50 GB, which works out to an average of 5 MB per generated asset before bandwidth becomes the constraint rather than credits. For a 1200 by 630 social card that is enormous headroom and you will never see it. For high resolution print output, for multi page PDFs, or for anything served repeatedly to end users rather than fetched once and stored, it is a ceiling you should at least calculate against.

The reason it matters here is that a credit comparison silently assumes credits are the only thing being counted. On four of these five vendors that is true. On one it is not, and the second meter is not in anybody's comparison table, including most of the ones that rank for this query.

Underneath the pricing there are two genuinely different products wearing the same category label, and picking the wrong kind costs more than picking the wrong price.

Template editor APIs (Bannerbear, Placid, Abyssale) give you a browser based visual editor. A designer builds a template, marks which layers are dynamic, and your code calls the API with values for those layers. The strength is that non engineers own the design and can change it without a deploy. The constraint is that the layout is the editor's model of a layout, so anything the editor cannot express, you cannot render.

Raw HTML rendering APIs (HTML/CSS to Image, html2img.com) take the HTML and CSS you send and paint it. The strength is that there is no ceiling on what you can express, because it is a browser and you already know how to lay things out in one. Existing CSS, webfonts, charting libraries and print stylesheets all work. The constraint is that the design lives in your codebase, so changing it is a code change.

The question that resolves it is not which is more powerful. It is who owns the design and how often does it change. Marketing owns it and changes it weekly, go with an editor. Engineering owns it, it comes out of your own data model, and it needs to be pixel accurate, go with raw HTML.

There is a third case that both of these handle badly, and it is common enough to be worth naming. If what you are producing is a document rather than a picture, an invoice, a statement, a policy, a signed agreement or a report, then you need real page breaks, repeating headers and footers, page numbering, selectable text and a predictable page size. An image API that happens to emit PDFs will give you a PDF, but it will give you one long page shaped like a picture. That is a different job and it wants a rendering API built for paged output. It is what we build, our PDF API pricing comparison prices that side of the market on the same normalized basis as this page, and the demo at the top of this page will render a real one for you now without an account.

On price alone for raw HTML rendering at ordinary volume, html2img.com wins this comparison. It is the cheapest at every shared rung, its PDF credit rule is the most generous in the group at one credit per render whatever the output, and it is the only vendor here whose published policy makes a PDF heavy workload cost exactly the same as an image workload. If you are under 100,000 renders a month and you want the lowest defensible number, that is the answer.

HTML/CSS to Image earns the premium in two situations. It is the only ladder in the group with published pricing above 100,000 a month, all the way to a million, so it is the one you can grow into without a sales call. And it publishes overage rates, which means an overrun degrades gracefully instead of failing. Both of those are worth real money to a team that cannot afford a hard stop.

Placid is the best value in the group if you are producing images at volume and you can use most of a 25,000 credit plan, where the in plan rate of $0.00356 is the lowest per credit figure anywhere in this table. It is also the only vendor that rolls unused credits over, which suits spiky workloads. Its two credits per PDF page rule is the one to model carefully before you commit, because for document output it is the most expensive rule in the group.

Bannerbear is the most established of the five and has the broadest no code integration surface, which is a legitimate reason to pay more when the people driving it are not engineers. Its credit ladder does discount steeply with volume, from $0.049 an image at 1,000 down to $0.00598 at 50,000. Weigh the unpublished PDF multiplier and the bandwidth ceiling before committing to a document workload on it.

Abyssale is a brand team tool priced per seat, and it should be evaluated against other brand team tools rather than against rendering APIs.

One last honest note about all five. They are excellent at turning a design into a picture. If your real requirement is a paged, text selectable, properly broken document that a person will file, sign or send to an accountant, none of them is built for that, and the cheapest of them will still be the wrong tool. If your templates are already HTML, our comparison of the best HTML to PDF APIs covers the vendors that are, and the template based PDF generators covers the middle ground where a visual editor emits real documents.