DEV Community: Mukul Dutt

Open Graph Image API: generate dynamic og:image URLs in one call

Mukul Dutt — Thu, 06 Aug 2026 05:12:48 +0000

Originally published on propzapi.com — cross-posted here.

Every one of your blog posts shares the same flat OG image. That's a thousand links on X and LinkedIn that all look identical, and forgettable. An Open Graph image API fixes that: one template, a per-page image.

What it does

You store one 1200×630 layout with {{variables}}, then sign a URL per post from that post's title. Drop the URL into <meta property="og:image">. The image renders the first time a crawler fetches it, then every refetch is cached and free.

Why not @vercel/og?

It's great if you're on Next.js and your card is simple. But it renders with Satori, a flexbox-only subset of CSS: no grid, no media queries, no pseudo-elements, and fonts limited to ttf/otf/woff with no ligatures. The day your design needs a font it won't load or a layout it won't do, you're rewriting. A full-Chromium API renders the CSS you already wrote.

The cost trap people miss

Facebook, Slack, LinkedIn and X hammer your og:image on every share and re-share. If you paid per fetch, a viral post would be a surprise bill. Sign the URL for free, render once on first fetch (one credit), and cache serves every share after. Cost tracks how many distinct images you make, not how popular they get.

Why isn't my og:image updating?

Almost always platform caching, not your API. Facebook and LinkedIn scrape once and hold it — force a re-scrape in their debugger. And the URL has to be absolute; a relative path works in your browser but not for an external crawler.

Full guide — sizes, the four ways to generate them, and the debugger workflow — in the Open Graph Image API guide, built on propzapi, which also does HTML-to-image, screenshots, and one-page PDFs.

HTML to PDF API: convert HTML to PDF in one call

Mukul Dutt — Thu, 06 Aug 2026 05:09:58 +0000

Originally published on propzapi.com — cross-posted here.

wkhtmltopdf is dead. The repo was archived in 2023, the last release was 2020, and it ships an unpatched critical SSRF (CVE-2022-35583). If your PDF pipeline still runs on it, you're shipping a 2012 browser engine with a security hole. Here's the modern version.

What an HTML to PDF API does

You send HTML (or a stored template id plus data), it renders the page in headless Chromium, and returns a URL to a finished PDF. Chromium prints with the same engine that draws your page in a browser, so your flexbox, grid, and web fonts come out right — no 2012 WebKit fork mangling the layout.

One call

curl https://api.propzapi.com/v1/images \
  -H "X-API-Key: pk_live_…" -H "Content-Type: application/json" \
  -d '{"template":"tpl_…","format":"pdf","data":{"number":"1042","total":"$4,200.00"}}'
# → { "url": "https://images.propzapi.com/img_….pdf", "width":794, "height":1123, "format":"pdf", "bytes":6679 }

Store an invoice or certificate template once with {{variables}}, then render per record. A common wiring: a payment webhook fires, your handler POSTs the template with that order's data, and you email the returned PDF URL. Billed on delivery — a failed render costs nothing.

The gotchas that bite everyone

Page size is CSS. A4 is 794×1123px at 96dpi, US Letter is 816×1056. Set margins with the @page rule.
Backgrounds get stripped by default — add print-color-adjust: exact or your dark header prints white.
Fonts and images: wait for webfonts to load before rendering, and use absolute URLs for anything the PDF shows (the render server has no session to authenticate with).

When not to reach for it

For a 40-page contract with running headers, page numbers, and footnotes, use a paged-media engine like Prince — Chromium's page-break control is uneven. Chromium is built for single-page outputs: invoices, receipts, tickets, certificates, one-page reports.

I wrote the full guide — self-host Puppeteer vs hosted, a comparison table, the WeasyPrint option, and every gotcha with its fix — in the HTML to PDF API guide, built on propzapi.

Bannerbear alternative: a pay-as-you-go image generation API

Mukul Dutt — Thu, 06 Aug 2026 05:07:00 +0000

Originally published on propzapi.com — cross-posted here.

Bannerbear is a good product. It's also a $49-a-month subscription and a visual editor, and neither of those is what every team wants. If you're a developer who renders images from data and would rather write HTML than click a canvas, here's the honest comparison.

What each one is

Bannerbear is a mature no-code media platform: design in a drag-and-drop editor, then generate images, video, and PDFs over an API. It has real strengths I won't pretend away — a video API, AI face-detection (2 credits per image), Smart Crop, batch generation, and years of production maturity.

propzapi is a developer-first image API: you store your own HTML/CSS templates with {{variables}}, render them to PNG/JPEG/WebP/PDF in headless Chromium, screenshot any URL, and pay per image instead of a subscription. It ships a first-party MCP server, so an agent can render an image as a tool call.

The price math

Bannerbear's entry tier is $49/mo for 1,000 images (about $0.049 each), and you pay it whether you render 40 or 1,000. propzapi's $5 pack is about $0.033 an image and never expires — so 200 images is a few dollars, not a monthly floor. The subscription only pulls ahead once your steady volume clears a few hundred a month.

Who should pick which

Choose Bannerbear if a non-developer owns the templates, you need video, or you want AI face-detection for user-uploaded photos. Choose propzapi if you render from data in code, want no monthly floor, and would rather write real CSS than work around an editor's limits.

I did the full feature-by-feature table, the sourced capability breakdown (video, face-detect, Smart Crop — all from Bannerbear's own docs), and a migration guide in the full comparison. It's built on propzapi, a pay-as-you-go image generation API for developers and agents.

HTML to Image API: turn HTML and CSS into a PNG in one call

Mukul Dutt — Thu, 06 Aug 2026 05:03:02 +0000

Originally published on propzapi.com — cross-posted here.

You already wrote the layout. It's a <div> with some CSS, and it looks right in your browser. Now you need it as a PNG, a few hundred times, one per row in your database. That gap, between a page you can see and an image file you can host, is the whole job.

What an HTML to image API actually does

You POST HTML (or a stored template id plus data), it renders that markup in real headless Chromium, and hands back a hosted PNG/JPEG/WebP URL. No browser to install, no canvas library, no fonts to wrangle. Your CSS in, a picture out.

The reason to reach for a service instead of a browser library like html-to-image or html2canvas: those run in the user's browser and taint the canvas the moment a cross-origin image or a webfont touches it, so the asset shows in the preview and then silently vanishes from the export. Server-side rendering sidesteps that entirely.

Why not just run Puppeteer yourself?

You can. The script is an afternoon. Then production shows up: a single headless Chrome instance runs 300–500MB of RAM and climbs past 1GB over time, needs system fonts installed, and crashes under concurrency. On Lambda the full Chromium binary blows the 250MB package limit, so you're on @sparticuz/chromium with a 2GB function and a bumped timeout. None of it is hard. It's just a browser you now operate, forever, to make pictures.

One call

curl https://api.propzapi.com/v1/images \
  -H "X-API-Key: pk_live_…" -H "Content-Type: application/json" \
  -d '{"template":"og-article","data":{"title":"Ship an image for every row"},"format":"png"}'
# → { "url": "https://images.propzapi.com/img_….png", "width":1200, "height":630, "bytes":95126 }

Store your own HTML once (with {{variables}}), then render it per record. Because it's full Chromium, whatever CSS works in your browser works in the image — flexbox, grid, gradients, web fonts. Not a stripped-down subset of it.

PNG, WebP or JPEG?

PNG for text and sharp edges, since it's lossless. WebP when there's a photo or a gradient in the frame (about 26% smaller). JPEG only for mostly-photo art. Set format and scale (2 for retina) per call.

When you don't need it

If you have five fixed images that never change, make them by hand in Figma and move on. An API earns its place when the images are per-record and unbounded — a card per post, an invoice per order, a certificate per user.

I wrote the full version — the self-host cost breakdown, a four-way comparison table, formats with real byte sizes, and the honest "when not to" — in the full HTML to Image API guide. It's built on propzapi, which also screenshots any URL, exports one-page PDFs, and ships an MCP server so an agent can render an image as a tool call.