DEV Community: Dan E

Render an HTML Table to PNG in Python (5 Ways, 2026)

Dan E — Sun, 07 Jun 2026 17:15:07 +0000

You have an HTML table — a financial summary, a report section, a styled DataFrame, a chart your frontend already renders — and you need it as a PNG from a Python backend. A cron job that emails a nightly report, an invoice rasterized into a PDF, a certificate generated per customer. The HTML is the easy part; turning it into a pixel-accurate image is where the options get messy.

This guide covers five working approaches, from a single API call to a headless browser you host yourself, plus an honest note on where each one bites. Every snippet renders the same little table so you can compare them directly. (All facts verified June 2026 — wkhtmltopdf is now archived, which changes the usual advice.)

Method 1: Rendex API (no browser to host)

The fastest path, and the one that needs nothing on your machine. POST the HTML to the Rendex rendering API and get PNG bytes back. A real, modern Chromium runs on Cloudflare's edge — you don't install, patch, or keep a browser alive, and modern CSS (Flexbox, Grid, web fonts) renders exactly as it would in Chrome.

# pip install rendex
from rendex import Rendex
from pathlib import Path

rendex = Rendex("YOUR_API_KEY")

html = """
<table style="border-collapse:collapse;font-family:system-ui;font-size:14px">
  <thead>
    <tr style="background:#f1f5f9">
      <th style="text-align:left;padding:8px 14px">Line item</th>
      <th style="text-align:right;padding:8px 14px">Amount</th>
    </tr>
  </thead>
  <tbody>
    <tr><td style="padding:8px 14px">Subscriptions</td>
        <td style="text-align:right;padding:8px 14px">€482,100</td></tr>
    <tr><td style="padding:8px 14px">Professional services</td>
        <td style="text-align:right;padding:8px 14px">€91,400</td></tr>
  </tbody>
</table>
"""

result = rendex.render_html(html, format="png", device_scale_factor=2)
Path("table.png").write_bytes(result.image)
print("Rendered", result.metadata)

Because the table is the only thing on the page, render at device_scale_factor=2 for a crisp 2× image, and add full_page=True when a long table runs past the viewport. No SDK? The same call over raw HTTP:

curl -X POST https://api.rendex.dev/v1/screenshot \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  --output table.png \
  -d '{
    "html": "<table style=\"border-collapse:collapse;font-family:system-ui\"><tr><th>Line item</th><th>Amount</th></tr><tr><td>Subscriptions</td><td>€482,100</td></tr></table>",
    "format": "png",
    "deviceScaleFactor": 2,
    "fullPage": true
  }'

When to use: production report pipelines, anything you deploy to a serverless function or a slim container, and any time you don't want a Chromium binary in your image. The free tier is 500 renders/month, no card — grab a key. For the full report-to-PDF-deliverable pattern (templating with a data{} object, embedding the PNG in a generated PDF), see the Python report-rendering recipe.

The trade-off, honestly: it's a network call and a per-render cost, and the HTML leaves your box. For a sync render Rendex processes it transiently and doesn't store it; if that's a dealbreaker for sensitive data, one of the self-hosted options below keeps everything local.

Method 2: html2image (lightweight, but you supply Chrome)

html2image is a thin wrapper around the headless mode of a Chrome/Chromium/Edge that is already installed on the machine — it doesn't bundle one. Maintained (latest 2.0.7, May 2025), MIT, and genuinely the simplest local route when a browser is already present.

# pip install html2image   (Chrome/Chromium/Edge must already be installed)
from html2image import Html2Image

hti = Html2Image()
html = "<table border=1><tr><th>Line item</th><th>Amount</th></tr>" \
       "<tr><td>Subscriptions</td><td>€482,100</td></tr></table>"

hti.screenshot(html_str=html, save_as="table.png", size=(600, 200))

Where it bites: you own keeping that Chrome patched and version-matched across every machine and CI runner, and fonts/emoji are whatever the host browser ships — Linux base images often lack CJK and color-emoji fonts, so you'll install font packages to avoid tofu boxes.

Method 3: Playwright (the modern self-hosted default)

If you're going to run a browser yourself, Playwright for Python is the current standard (1.60, May 2026, with evergreen bundled browsers). set_content() loads your HTML; locate the table and screenshot just that element.

# pip install playwright  &&  playwright install chromium
from playwright.sync_api import sync_playwright

html = "<table border=1><tr><th>Line item</th><th>Amount</th></tr>" \
       "<tr><td>Subscriptions</td><td>€482,100</td></tr></table>"

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page()
    page.set_content(html)
    page.locator("table").screenshot(path="table.png")  # crop to the table
    browser.close()

Where it bites: the bundled browsers are hundreds of MB in your image; you patch them; and a long-running process leaks memory and leaves zombie processes if you don't close contexts. Full-page shots over ~16,384px can OOM. Great control — you just operate the browser fleet now.

Method 4: imgkit / wkhtmltoimage (works, but the engine is archived)

imgkit wraps the wkhtmltoimage binary. It's the classic answer to this question, and the one to be most careful with in 2026.

# pip install imgkit   +   system binary: apt-get install wkhtmltopdf
import imgkit

html = "<table border=1><tr><th>Line item</th><th>Amount</th></tr>" \
       "<tr><td>Subscriptions</td><td>€482,100</td></tr></table>"

imgkit.from_string(html, "table.png")  # headless box: wrap in xvfb-run

Where it bites: the underlying wkhtmltoimage/wkhtmltopdf engine was archived in January 2023 (last stable release June 2020) and gets no security patches. It's a frozen, old WebKit: modern CSS Flex/Grid, web fonts, and emoji are broken or silently dropped, and on a headless server it throws QXcbConnection: Could not connect to display unless you wrap every call in xvfb-run. imgkit itself is effectively unmaintained (last release 1.2.3). Fine for a legacy script; not what you'd start a new project on.

Method 5: Selenium (works, heaviest for one PNG)

Selenium drives a real browser and can screenshot an element. It's maintained and battle-tested, but it's the most boilerplate for "HTML string → one PNG."

# pip install selenium   (Selenium Manager fetches a matching ChromeDriver)
import urllib.parse
from selenium import webdriver
from selenium.webdriver.chrome.options import Options

html = "<table border=1><tr><th>Line item</th><th>Amount</th></tr>" \
       "<tr><td>Subscriptions</td><td>€482,100</td></tr></table>"

opts = Options()
opts.add_argument("--headless=new")
driver = webdriver.Chrome(options=opts)
driver.get("data:text/html;charset=utf-8," + urllib.parse.quote(html))
driver.find_element("tag name", "table").screenshot("table.png")
driver.quit()

Where it bites: the classic SessionNotCreatedException when ChromeDriver and the host Chrome drift apart (Selenium Manager mostly handles this now), full-page screenshots aren't first-class, and it's the same browser-fleet ownership as Playwright with more ceremony.

A note on WeasyPrint

WeasyPrint comes up in every "HTML to image" search, so it's worth being precise: it's an excellent, actively-maintained pure-Python engine — but it renders to PDF only (PNG export was removed in v53) and runs no JavaScript. If your table is static HTML/CSS and you actually want a PDF, WeasyPrint is a great, dependency-light choice and you don't need any of the above. If you need a PNG, or your table/chart is built by JavaScript, it can't do the job without a second PDF→PNG conversion step.

Which one should you use?

Approach	Browser to host?	PNG?	Best for
Rendex API	No (runs on the edge)	Yes	Production pipelines, serverless, no infra to own
html2image	Yes (you supply Chrome)	Yes	Quick local jobs where a browser is already present
Playwright	Yes (bundled)	Yes	Full browser control, if you want to run the fleet
imgkit / wkhtmltoimage	No (archived engine)	Yes	Legacy scripts only — engine archived 2023
Selenium	Yes	Yes (viewport)	Teams already standardized on Selenium
WeasyPrint	No	No (PDF only)	Static HTML → PDF, no JS

The honest summary: the self-hosted libraries all work — the real question is whether you want to own a browser (install, patch, scale, debug fonts, watch memory) for what is often a side-task to your actual report logic. If yes, Playwright is the modern pick. If you'd rather keep your deployment a plain Python service and POST HTML to get a PNG back, that's exactly what Rendex is for — 500 free renders a month to prove the pipeline before you scale.

Render a Chart to an Image on the Server (Node + Python, 2026)

Dan E — Sat, 06 Jun 2026 17:12:31 +0000

You need a chart as a static image on the server — to attach to an email, embed in a generated PDF, post to Slack, or drop into a nightly report. Not an interactive widget in a browser; a PNG, generated headless, no human watching.

Here's the thing nobody says up front: almost every server-side "chart to image" route eventually drags in one of two heavy dependencies — a C/C++ canvas stack (Cairo/Skia via node-canvas) or a headless Chrome. The choice is really which one you want to own. This guide walks the honest options across Node and Python (verified June 2026, including the kaleido and orca changes that broke a lot of old tutorials), then the route that moves the browser off your box entirely.

Method 1: Render the chart's HTML with an API (no canvas, no Chrome to host)

If your chart can be expressed as HTML — a Chart.js <canvas>, an ECharts container, an SVG, or even a styled HTML/CSS bar chart — you can POST that HTML to the Rendex rendering API and get a PNG back. Rendex runs a real, modern headless browser on the edge, so the chart library's JavaScript actually executes; you don't install node-canvas, compile native modules, or keep a Chrome alive.

# pip install rendex
from rendex import Rendex
from pathlib import Path

rendex = Rendex("YOUR_API_KEY")

# A self-contained HTML page with Chart.js from a CDN. animation:false so the
# chart is fully drawn by the time Rendex captures it.
html = """
<!doctype html><html><head>
  <script src="https://cdn.jsdelivr.net/npm/chart.js"></script>
</head><body style="margin:0;width:800px">
  <canvas id="c" width="800" height="400"></canvas>
  <script>
    new Chart(document.getElementById('c'), {
      type: 'bar',
      data: {
        labels: ['Q1','Q2','Q3','Q4'],
        datasets: [{ label: 'Revenue (€k)', data: [482, 591, 623, 705],
                     backgroundColor: '#ea580c' }]
      },
      options: { animation: false, responsive: false,
                 plugins: { legend: { display: true } } }
    });
  </script>
</body></html>
"""

result = rendex.render_html(html, format="png", width=800, height=400,
                            device_scale_factor=2)
Path("chart.png").write_bytes(result.image)
print("Rendered", result.metadata)

Already produce charts as SVG (ECharts SSR, D3, a matplotlib SVG export) or as a styled HTML table? Pass that markup directly — same call, no JavaScript needed. 500 free renders/month, no card to start: get a key.

The honest trade-off: this doesn't make Chrome disappear — it relocates it onto Rendex's infrastructure. You give up nothing technically hard; you pay a per-render fee, a network hop, and you send the chart markup to a vendor (a sync render is processed transiently and not stored). You gain: no node-gyp, no libcairo/libpango in your image, no Chromium-in-CI, no font-package debugging, no kaleido-version breakage.

Method 2: Chart.js + chartjs-node-canvas (Node, no browser)

The canonical Node route renders Chart.js onto a node-canvas surface — no browser, but you inherit node-canvas's native Cairo/Pango dependency.

// npm i chartjs-node-canvas chart.js
// + system libs: apt-get install libcairo2-dev libpango1.0-dev libjpeg-dev libgif-dev
import { ChartJSNodeCanvas } from "chartjs-node-canvas";
import { writeFileSync } from "fs";

const canvas = new ChartJSNodeCanvas({ width: 800, height: 400 });
const png = await canvas.renderToBuffer({
  type: "bar",
  data: { labels: ["Q1","Q2","Q3","Q4"],
          datasets: [{ label: "Revenue", data: [482,591,623,705] }] },
});
writeFileSync("chart.png", png);

Where it bites: node-canvas's native build fails on fresh Node majors, Alpine, and ARM until prebuilt binaries catch up; fonts must be installed in the image or text renders as boxes. For new projects, the Skia-based @napi-rs/canvas or skia-canvas ship N-API prebuilts and avoid the compile (the old canvas-prebuilt package is discontinued — don't use it).

Method 3: matplotlib savefig (Python, the lightest deps)

For Python, matplotlib with the Agg backend is the only genuinely browser-free and Cairo-free PNG path.

# pip install matplotlib
import matplotlib
matplotlib.use("Agg")            # MUST be set before importing pyplot (headless)
import matplotlib.pyplot as plt

fig, ax = plt.subplots(figsize=(8, 4), dpi=150)
ax.bar(["Q1","Q2","Q3","Q4"], [482, 591, 623, 705], color="#ea580c")
ax.set_title("Revenue (€k)")
fig.savefig("chart.png", bbox_inches="tight")
plt.close(fig)                   # close every figure or you leak memory in a loop

Where it bites: you must force Agg before importing pyplot or it tries a GUI and crashes headless; missing system fonts silently drop glyphs (especially CJK); and you leak memory if you forget plt.close() in a loop. Great for native matplotlib charts; it won't render an HTML/CSS report or a JS charting library.

Method 4: pandas DataFrame → image (secretly headless Chrome)

The popular dataframe-image turns a styled DataFrame into a PNG — and its default backend shells out to a local Chrome, which surprises people in containers and CI.

# pip install dataframe_image   (default backend needs a local Chrome)
import dataframe_image as dfi
import pandas as pd

df = pd.DataFrame({"Quarter": ["Q1","Q2","Q3","Q4"], "Revenue": [482,591,623,705]})
styled = df.style.background_gradient(subset=["Revenue"], cmap="Oranges")
dfi.export(styled, "table.png")   # uses local Chrome by default

Where it bites: the default chrome backend is brittle in headless environments (it fails in Google Colab; you switch to the selenium/Firefox or matplotlib backends); the matplotlib fallback only simulates the default table style (no custom CSS, no captions). Note df2img pins the deprecated kaleido v0 line — a maintenance risk for new code. If you're already styling the DataFrame as HTML (df.style.to_html()), you've produced markup, not pixels — rendering it is the same Chrome problem, which is exactly what an HTML-render API solves (Method 1).

Method 5: Plotly — mind the kaleido break

Plotly's static export is the route most affected by 2025/26 changes. fig.to_image() uses kaleido, but kaleido v1 no longer bundles Chromium — if no compatible Chrome is on the box, export errors.

# pip install --upgrade plotly kaleido
# kaleido v1 does NOT ship a browser — install Chrome or run: kaleido_get_chrome
import plotly.graph_objects as go

fig = go.Figure(go.Bar(x=["Q1","Q2","Q3","Q4"], y=[482,591,623,705]))
fig.write_image("chart.png")   # engine auto = kaleido (needs system Chrome)

Where it bites: the old engine="orca" path is deprecated and removed after September 2025 — migrate to kaleido. And kaleido v0 (bundled Chromium) is superseded by v1 (bring your own Chrome), so guides that rely on the bundled browser are stale.

Method 6: ECharts SSR — zero-dependency, but SVG not PNG

Apache ECharts can render server-side with no native dependency at all — the catch is it outputs an SVG string, not a raster.

// npm i echarts   (no Cairo, no Chrome — cleanest native-free route)
import * as echarts from "echarts";

const chart = echarts.init(null, null, { renderer: "svg", ssr: true, width: 800, height: 400 });
chart.setOption({
  xAxis: { type: "category", data: ["Q1","Q2","Q3","Q4"] },
  yAxis: { type: "value" },
  series: [{ type: "bar", data: [482,591,623,705] }],
});
const svg = chart.renderToSVGString();   // SVG markup — rasterize for email/PDF

Where it bites: if the consumer needs a PNG (email, Slack, a PDF embed), you still have to rasterize that SVG — via resvg, Sharp, or a browser. ECharts SSR gets you clean markup with no deps; turning it into pixels re-introduces a renderer. (That SVG is also a perfectly good input to POST to a rendering API — back to Method 1.)

Which one should you use?

Approach	Heavy dependency	Output	Best for
Rendex API (HTML/SVG → PNG)	None on your box	PNG / PDF	Charts already expressible as HTML/SVG; no infra to own
Chart.js + node-canvas	Cairo/Pango (native)	PNG	Node apps that can carry the native build
matplotlib (Agg)	None (bundled C ext)	PNG	Native matplotlib charts; lightest Python deps
dataframe-image	Headless Chrome	PNG	Styled pandas DataFrames (if Chrome is present)
Plotly + kaleido v1	System Chrome	PNG	Plotly figures (install Chrome separately)
ECharts SSR	None	SVG (rasterize for PNG)	Clean markup; you handle rasterization

The honest takeaway: there is no painless "draw some pixels" path that scales — you either own a native canvas stack or a headless browser. The in-process options (matplotlib, node-canvas) work well if you accept their build and font upkeep; ECharts SSR is clean but stops at SVG. If your charts and tables are already HTML/CSS/SVG — which, for most report and dashboard work, they are — the least infra is to POST that markup to Rendex and let the browser live somewhere else. See the Python report-rendering recipe for the full pattern, or rendering an HTML table to PNG for the table case.

Best HTML-to-PDF Tools in 2026 (APIs + Libraries)

Dan E — Fri, 05 Jun 2026 17:53:14 +0000

Best HTML-to-PDF Tools in 2026 (APIs + Libraries)

Every production web app eventually needs HTML-to-PDF. The options range from zero-setup APIs to self-hosted headless browsers, and picking the wrong one means either managing Chromium memory leaks in production or paying per-call rates that don't fit your volume.

This roundup covers five tools against consistent criteria: CSS and JavaScript rendering quality, integration time, pricing model, and honest weaknesses. Five tools covered: Rendex, DocRaptor, PDFShift, wkhtmltopdf, and Playwright.

How These Tools Were Evaluated

CSS rendering: flexbox, grid, CSS custom properties, @media print support
JavaScript execution: waits for dynamic content, React/Vue/Svelte app rendering
Integration time: minutes from sign-up to first PDF
Pricing: free tier, per-call cost at 10k/month, overage handling
Infrastructure burden: managed API vs. you own the servers

1. Rendex API

Rendex runs Chromium on Cloudflare's global edge network. You POST a URL or raw HTML, get back a PDF. No browser to install, no memory to manage, no cold starts from a containerized Chrome.

# Replace rdx_live_YOUR_KEY with a key from https://rendex.dev/login
curl -X POST https://api.rendex.dev/v1/screenshot \
  -H "Authorization: Bearer rdx_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "format": "pdf",
    "pdfFormat": "A4",
    "pdfMargin": "20mm",
    "pdfPrintBackground": true
  }' --output output.pdf

HTML-to-PDF works the same way. Swap the url field for an html field with your template string. Useful for invoice generation where the page never needs to exist at a public URL.

curl -X POST https://api.rendex.dev/v1/screenshot \
  -H "Authorization: Bearer rdx_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<h1>Invoice #1042</h1><p>Amount due: $250</p>",
    "format": "pdf",
    "pdfFormat": "Letter",
    "pdfPrintBackground": true
  }' --output invoice.pdf

The API reference covers page size options (A4, Letter, Legal, Tabloid), landscape mode, margin control, and scale. Python and JavaScript SDKs are available for both sync and async workflows.

For a deeper Python walkthrough, see How to Generate PDFs from URLs in Python.

Strengths: Full Chromium rendering, no infrastructure to run, global edge delivery, async batch jobs for high-volume workloads, geo-targeting on Pro plans.

Weaknesses: Monthly call caps per plan. If you need truly unlimited volume at predictable cost, the pricing model may not fit. The free tier gives you 500 calls/month to test before committing.

Pricing: Free tier (500 calls/month). Paid plans available at rendex.dev/pricing.

2. DocRaptor

DocRaptor uses the Prince XML rendering engine, which has been the reference implementation for the CSS Paged Media specification for over a decade. It handles complex print layouts, running headers and footers, page numbering, and advanced typographic features that Chromium-based tools handle inconsistently.

The trade-off is cost. DocRaptor is priced for document-heavy enterprise workflows, not high-volume automated generation. It excels at reports that need precise pagination control and legal or publishing workflows where print CSS compliance matters more than price per call.

Strengths: Best-in-class CSS Paged Media support, predictable print layout, long track record in publishing and legal tech.

Weaknesses: Expensive at scale. Not ideal for consumer-facing workflows with high call volumes. Fewer options for JavaScript-heavy SPAs compared to Chromium-based tools.

Best for: Legal documents, publishing pipelines, reports where pagination precision outweighs cost.

3. PDFShift

PDFShift is a hosted HTML-to-PDF API backed by a headless Chromium instance. The integration surface is minimal: one endpoint, one JSON body with source, landscape, margin, and a handful of other options.

PDFShift offers an EU-hosted option for teams with data residency requirements, which DocRaptor and some other APIs do not. Pricing is credit-based, which can be more cost-effective than per-call pricing if your usage is bursty.

Strengths: Simple API, EU data residency option, credit-based pricing suits variable workloads, good JavaScript support.

Weaknesses: Less established ecosystem than Puppeteer or DocRaptor. Credit expiration on some plans can be a surprise. Fewer geographic edge locations than Cloudflare-backed options.

Best for: Teams that need EU hosting, developers who want a simpler API surface than a full-featured rendering platform.

4. wkhtmltopdf

wkhtmltopdf is a command-line tool that converts HTML to PDF using a patched version of the QtWebKit engine. It requires no API call, works offline, and ships as a single binary in most Linux package managers.

# Install: apt install wkhtmltopdf
# Convert URL to PDF
wkhtmltopdf \
  --page-size A4 \
  --margin-top 20mm --margin-bottom 20mm \
  --margin-left 20mm --margin-right 20mm \
  --print-media-type \
  https://example.com output.pdf

The problem is the engine. QtWebKit is effectively frozen at a 2012-era rendering baseline. Flexbox works partially, CSS Grid does not, and CSS custom properties are not supported. The project has been unmaintained since 2020. Modern web apps built with React, Vue, or Tailwind will render incorrectly or not at all.

Strengths: No API key required, no internet connection needed, fast for simple pages, available on every Linux distribution.

Weaknesses: Outdated WebKit engine, no CSS Grid or custom property support, limited JavaScript execution, effectively unmaintained. Not usable for modern SPAs.

Best for: Simple static HTML pages on isolated servers, legacy systems where adding an API call is not an option. Avoid for anything built in the last five years.

5. Playwright (Self-Hosted Chromium)

Playwright gives you a full Chromium browser under programmatic control. PDF generation uses the same print engine as Chrome's built-in Save as PDF, which means you get accurate rendering for any modern CSS layout. You can authenticate, dismiss banners, wait for specific elements, and inject CSS before capture.

// npm install playwright
// npx playwright install chromium
const { chromium } = require("playwright");

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto("https://example.com", { waitUntil: "networkidle" });
  await page.pdf({
    path: "output.pdf",
    format: "A4",
    margin: { top: "20mm", bottom: "20mm", left: "20mm", right: "20mm" },
    printBackground: true,
  });
  await browser.close();
})();

The cost is infrastructure. Chromium uses ~300MB of RAM per browser instance. In a containerized environment with concurrent requests, you need to manage a browser pool, handle process crashes, and size your instances for peak load. On serverless platforms, Chromium requires special handling or a layer, and cold starts can add significant latency.

Strengths: Full modern CSS support, browser interaction before capture (logins, cookie banners, dynamic content), no per-call cost once running.

Weaknesses: Heavy infrastructure cost. Memory leaks in long-running processes are a real problem. Not practical on serverless without workarounds. You own the uptime, scaling, and maintenance.

Best for: Teams that already run their own server infrastructure, workflows requiring browser interaction before PDF generation, high-volume scenarios where per-call API pricing becomes prohibitive.

Comparison

Tool	Engine	CSS Grid	Hosted	Free Tier	Best For
Rendex	Chromium	Yes	Yes (CF edge)	500/mo	APIs, agents, batch jobs
DocRaptor	Prince XML	Yes	Yes	Trial only	Legal, publishing, print CSS
PDFShift	Chromium	Yes	Yes (EU option)	Trial credits	EU data residency
wkhtmltopdf	QtWebKit	No	No (CLI)	Free/open source	Simple legacy pages
Playwright	Chromium	Yes	No (self-host)	Free/open source	Self-hosted, browser interaction

Which to Pick

You need a PDF in under an hour with working CSS: Rendex or PDFShift. Both are Chromium-backed APIs with free trials. Rendex includes batch jobs and MCP support for agent pipelines if that matters to your workflow.

You need complex print layouts: DocRaptor. Prince XML's CSS Paged Media support is the best available. You'll pay for it, but the output quality for complex multi-page documents is not matched by Chromium-based tools.

You have a data residency requirement (EU): PDFShift offers EU-hosted infrastructure. Verify their current data processing agreement before committing.

You run your own servers and need browser interaction: Playwright. Use it when the page requires authentication or dynamic interaction before PDF generation, and when you already have the infrastructure to run it.

You have simple static pages and no API budget: wkhtmltopdf gets the job done on pages from 2015. If the page uses Tailwind, React, or any modern CSS, expect problems.

See the URL-to-PDF use case page for a detailed breakdown of Rendex capabilities and integration patterns.

Next Steps

The fastest way to test any of the API options is the free URL-to-PDF tool: paste a URL, get a PDF back, no sign-up required. It uses the same Rendex rendering pipeline as the API.

Ready to automate? Get a free API key (500 calls/month, no credit card) and convert your first URL to PDF in under five minutes.

How to Convert Markdown to PDF with an API (2026)

Dan E — Sat, 30 May 2026 17:02:48 +0000

How to Convert Markdown to PDF with an API (2026)

Markdown is everywhere: README files, AI-generated docs, internal notes, changelogs. When you need to ship a PDF from that content, the standard options are headless Chrome (memory leaks, cold starts, ops overhead) or a three-step pipeline that converts Markdown to HTML, then HTML to PDF, across separate services. The markdown to pdf api in Rendex collapses that to one POST request.

You pass a raw Markdown string. The API converts it to a styled HTML document server-side and renders it to a PDF or PNG. No Chromium to manage, no intermediate files, no conversion library to pin.

What you need

An API key from rendex.dev/login (free tier: 500 calls/month)
curl, Python 3.8+, or Node.js 18+

Step 1: Make the API call

The POST /v1/screenshot endpoint accepts a markdown field alongside url and html. The three are mutually exclusive: pick one per request.

# Get your API key at rendex.dev/login
curl -X POST https://api.rendex.dev/v1/screenshot \
  -H "Authorization: Bearer rdx_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "markdown": "# Q2 Report\n\n## Revenue\n\n- APAC: $18k\n- EMEA: $14k",
    "format": "pdf",
    "pdfFormat": "A4",
    "pdfPrintBackground": true
  }' \
  --output report.pdf

The markdown field accepts up to 5 MB of Markdown text. The API converts it to HTML using a GitHub-flavored stylesheet before rendering, so standard Markdown syntax (headings, tables, fenced code blocks, inline code, blockquotes) renders as expected.

The format parameter controls the output type: "pdf" returns a PDF document, "png", "jpeg", and "webp" return images of the rendered page. pdfFormat accepts A4, Letter, Legal, Tabloid, and A3.

Step 2: Capture the full document

By default, the viewport height is 800px. For long Markdown documents, add fullPage: true to capture the entire rendered height rather than just the above-the-fold view. This has no effect on PDF output, which always renders full-page, but matters for PNG and JPEG.

curl -X POST https://api.rendex.dev/v1/screenshot \
  -H "Authorization: Bearer rdx_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "markdown": "# Docs\n\n## Section 1\n\nContent here.\n\n## Section 2\n\nMore content.",
    "format": "png",
    "fullPage": true
  }' \
  --output docs.png

Step 3: Use the Python SDK

The Rendex Python SDK ships a render_markdown method that wraps the markdown to pdf api call and handles authentication, camelCase conversion, and response parsing.

# pip install rendex
from rendex import Rendex
from pathlib import Path

# Get your API key at rendex.dev/login
rendex = Rendex("rdx_live_YOUR_KEY")

md = """# Q2 Report

Generated: 2026-05-27

## Revenue

| Region  | Q1   | Q2   |
|---------|------|------|
| APAC    | $12k | $18k |
| EMEA    | $9k  | $14k |

## Notes

- Compare against **Q1 targets** before sharing.
- Export as PDF before the 3pm review.
"""

result = rendex.render_markdown(md, format="pdf", pdf_format="A4")
Path("q2-report.pdf").write_bytes(result.image)
print(f"PDF written: {result.metadata.bytes_size} bytes")

render_markdown is a convenience wrapper over screenshot(markdown=...). Both accept the same keyword arguments in snake_case, which the SDK converts to camelCase before sending the request.

Step 4: Use the JavaScript SDK

The TypeScript SDK on npm (@copperline/rendex) exposes renderMarkdown, a typed wrapper over screenshot({ markdown }).

// npm install @copperline/rendex
import { Rendex } from "@copperline/rendex";
import { writeFile } from "node:fs/promises";

// Get your API key at rendex.dev/login
const rendex = new Rendex("rdx_live_YOUR_KEY");

const markdown = `# Release Notes

## v2.1.0

- Fixed auth timeout on long requests
- Added batch capture support (up to 500 URLs per job)
- Improved PDF margin defaults
`;

const { image } = await rendex.renderMarkdown(markdown, {
  format: "pdf",
  pdfFormat: "A4",
  pdfPrintBackground: true,
});

await writeFile("release-notes.pdf", Buffer.from(image));
console.log("release-notes.pdf written");

Step 5: Override the default styles

The default stylesheet is GitHub-flavored: 16px system font, max-width: 768px, bordered H1 and H2, code blocks with a light gray background. To match your brand, pass a css string (up to 50 KB). It is injected after the default stylesheet, so it wins the cascade.

curl -X POST https://api.rendex.dev/v1/screenshot \
  -H "Authorization: Bearer rdx_live_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "markdown": "# Custom Report\n\nStyled with custom CSS.",
    "format": "pdf",
    "css": "body.rendex-markdown { max-width: 960px; font-size: 14px; } body.rendex-markdown h1 { color: #ea580c; border-bottom-color: #ea580c; }"
  }' \
  --output styled.pdf

Target body.rendex-markdown to override the container, or use any standard CSS selector.

What you can generate

Markdown mode gives you clean GitHub styling out of the box. Layer a css string on top, or switch to html mode, and the same render pipeline turns plain input into production documents: invoices, reports, certificates, packing slips.

The pipeline handles long-form documents just as well. Author the body in Markdown and theme it with a css string, or hand Rendex finished HTML.

Markdown mode vs HTML mode

Use the markdown parameter when your source is already Markdown and the default GitHub styling is close enough. Use the html parameter when you need precise control over layout, custom fonts loaded from a CDN, or pixel-level design fidelity. The markdown pipeline adds a conversion step; HTML mode passes your markup directly to the renderer. Either way, the css parameter can push styles on top.

Both modes support Mustache templating via the data parameter. Pass {"data": {"name": "Alice"}} alongside your markdown string and use {{name}} in the Markdown body. The server fills the template before rendering. See the Markdown-to-Image tool to try this in the browser without writing any code.

Troubleshooting

VALIDATION_ERROR: Provide exactly one of 'url', 'html', or 'markdown': the request body includes more than one source field. Remove url or html if you are using markdown.

PAYLOAD_TOO_LARGE: the Markdown string exceeds 5 MB, or the data object exceeds 256 KB serialized. Split large documents or trim the data payload.

Tables or fenced code blocks not rendering: the default parser enables HTML mode so embedded HTML tags render as authored. Tables use standard GFM syntax (pipe-separated). Fenced blocks with a language identifier render without syntax highlighting; syntax coloring requires custom CSS or a client-side library.

Font not loading in rendered output: the renderer fetches web fonts from the URL in your @import statement. If the font domain requires authentication or uses a private CDN, the renderer falls back to the system font. Use a public URL.

PDF missing page breaks between sections: add a CSS page-break rule to the css param: h2 { page-break-before: always; }. The first H2 in the document will still start on page one; subsequent H2s will open new pages.

Next steps

The markdown to pdf api is one input mode of the same rendering pipeline. The same endpoint accepts a URL or raw HTML. For URL-to-PDF patterns in Python, see URL to PDF with Python.

To try Markdown rendering in the browser without an API key, use the Markdown-to-Image tool. Paste your content, pick PNG or PDF, and download the result.

Start for free at rendex.dev/login. The free tier covers 500 calls/month. No credit card required.

Why Self-Hosted Puppeteer Costs More Than a Screenshot API

Dan E — Fri, 29 May 2026 18:31:37 +0000

Why Self-Hosted Puppeteer Costs More Than a Screenshot API

Puppeteer works until it doesn't. Early in a project, running Chrome on a $20 VPS feels fine. Then traffic grows, concurrent requests pile up, and the tab that should take two seconds starts taking forty. Memory climbs. The process crashes. You add a cron job to restart it and call it done. Six months later, you have a team member whose job is keeping Chrome alive.

This is the puppeteer vs screenshot api decision most teams make reactively instead of proactively. Below is a concrete cost breakdown of self-hosted Puppeteer, where the math tips toward an API, and when DIY still makes sense.

What Self-Hosted Actually Costs

Chrome is expensive to run. Each browser instance holds its own V8 heap, network stack, and renderer processes. A single headless Chrome tab uses roughly 300-400 MB of RAM at idle and spikes higher during active rendering. At five concurrent requests, that is 1.5-2 GB just for the browser, before your application server, database, or anything else running on the box.

Here is a realistic monthly breakdown for a team running 5,000 screenshots per month at low-to-moderate concurrency (five parallel captures):

Cost Category	Monthly Estimate	Notes
EC2 t3.xlarge (4 vCPU, 16 GB)	~$120	Minimum for five concurrent tabs plus OS headroom
EBS storage + data transfer	~$15	OS image, Chrome binary, screenshot output
S3 storage for output files	~$10	At ~150 KB average per screenshot (WebP)
Monitoring + alerting	~$20	Datadog, Better Uptime, or equivalent
Engineering maintenance	~$300-900	2-6 hrs/month at $150/hr. Often more.
Total	~$465-1,065	Before incident response time

The engineering maintenance figure is the one teams consistently undercount. Chromium updates break headless behavior. Puppeteer version bumps require regression testing. Memory leaks surface in production at 3 AM. Docker images grow. You add a queue. You add retries. Each fix is small; the total is a part-time job.

Costs That Never Appear on the Cloud Bill

Beyond line items, self-hosted Puppeteer carries invisible costs:

Cold starts in serverless environments. Chrome cannot run inside AWS Lambda at normal function sizes or in Cloudflare Workers on the standard tier. If you need serverless, you end up with a sidecar service or a library like @sparticuz/chromium, which adds latency, maintenance, and its own version fragility.
Geo-targeting is a separate problem. If a client needs screenshots from a specific country, self-hosted requires a proxy layer on top of Chrome. That is another vendor, another failure point, and another monthly line item.
Burst capacity requires manual work. A batch of 500 URLs submitted at once will overwhelm a single instance. Scaling horizontally means a queue, a scheduler, and multiple Chrome processes coordinated across machines.
Storage and delivery are your problem. Screenshots need to land somewhere accessible. S3 with signed URLs, CDN configuration, expiry policies, and access control are all table-stakes work that an API handles for you.
Security patching. Chrome ships security updates frequently. Each one requires you to pull a new image, test, and redeploy. On a managed API, the vendor handles this.

What the API Approach Looks Like

The puppeteer vs screenshot api calculation changes when you count the full cost of self-hosted. Here is the same task using a dedicated rendering API:

# One request, no infrastructure to manage
curl -X POST https://api.rendex.dev/v1/screenshot \
  -H "Authorization: Bearer rdx_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "url": "https://example.com",
    "format": "webp",
    "fullPage": true
  }' --output screenshot.webp
# Get your key at https://rendex.dev/login

Or using the JavaScript SDK:

// npm install @copperline/rendex
import { Rendex } from "@copperline/rendex"

// Get your key at https://rendex.dev/login
const rendex = new Rendex("rdx_your_key")

const { image, metadata } = await rendex.screenshot({
  url: "https://example.com",
  format: "webp",
  fullPage: true,
})

// image is a Buffer — write to disk or upload directly

At 5,000 captures per month, cost lands on the Starter plan. Compare that to the $465-1,065 range above. The 500 free calls per month on the free tier let you validate the integration before spending anything.

For a feature-by-feature comparison with pricing, the Rendex vs ScreenshotOne breakdown covers both products honestly, including where ScreenshotOne has the edge. And if you need to process URLs in bulk, the async batch rendering overview shows how queue-based workflows operate.

When Self-Hosted Puppeteer Wins

Self-hosted is the right call in specific situations:

You already run Playwright or Puppeteer for testing. If your CI pipeline runs browser tests on a dedicated fleet, adding screenshot generation on the same infrastructure costs almost nothing marginal.
You need multi-step browser interaction before capture. Login flows, cookie banners that require clicks, SPAs that navigate through several states before reaching the target view. APIs can inject cookies and headers, but a full click-through auth flow still requires self-hosted control.
Volume is very high and you are cost-sensitive. Above roughly 100,000 screenshots per month, a dedicated server may cost less than per-call API pricing. Run the numbers at your actual volume.

The pattern: teams with fewer than 50,000 captures per month and no existing browser automation fleet almost always come out ahead on total cost with an API. Teams above that threshold with infrastructure already in place often find self-hosted cheaper on compute, though the operational overhead rarely disappears entirely.

Try the API Side of the Comparison

The quickstart guide gets you from zero to your first screenshot in under five minutes. The free tier includes 500 calls per month with no credit card required. If you want to test before writing any code, the browser-based screenshot tool runs a live capture against any public URL.

If you're still deciding, start with the free tier on a single service or pipeline and measure. The difference in operational load is usually apparent within a week. Get a free API key and see where the time actually goes.

How to Convert HTML to an Image with an API (2026)

Dan E — Fri, 10 Apr 2026 23:09:52 +0000

Converting HTML to an image is one of the most useful rendering operations in modern development. Social cards, invoices, OG images, email previews, and certificates — all start as HTML templates and need to become PNGs or JPEGs.

This guide covers three approaches: a dedicated rendering API (fastest to ship), Puppeteer (the DIY standard), and a serverless function with Satori (for React-specific templates). Each includes working code you can copy and run.

Method 1: Rendex API (Fastest)

The Rendex HTML-to-image API handles browser rendering on Cloudflare's edge network. Pass HTML as a string, get back a PNG, JPEG, WebP, or PDF. No Chromium install, no infrastructure.

# pip install rendex
from rendex import Rendex
from pathlib import Path

rendex = Rendex("YOUR_API_KEY")

html = """
<div style="width:1200px;height:630px;display:flex;align-items:center;
  justify-content:center;background:linear-gradient(135deg,#667eea,#764ba2);
  font-family:system-ui;color:white;font-size:48px;font-weight:bold;">
  Hello from Rendex
</div>
"""

result = rendex.screenshot(html=html, format="png", width=1200, height=630)
Path("card.png").write_bytes(result.image)
print(f"Generated {result.metadata.bytes_size} bytes")

The equivalent JavaScript SDK call:

import Rendex from "@copperline/rendex";
import { writeFileSync } from "fs";

const rendex = new Rendex("YOUR_API_KEY");

const html = `
<div style="width:1200px;height:630px;display:flex;align-items:center;
  justify-content:center;background:linear-gradient(135deg,#667eea,#764ba2);
  font-family:system-ui;color:white;font-size:48px;font-weight:bold;">
  Hello from Rendex
</div>
`;

const result = await rendex.screenshot({ html, format: "png", width: 1200, height: 630 });
writeFileSync("card.png", Buffer.from(result.image));

Or with raw HTTP — no SDK needed:

curl -X POST https://api.rendex.dev/v1/screenshot \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "html": "<div style=\"width:1200px;height:630px;display:flex;align-items:center;justify-content:center;background:linear-gradient(135deg,#667eea,#764ba2);font-family:system-ui;color:white;font-size:48px;font-weight:bold;\">Hello from Rendex</div>",
    "format": "png",
    "width": 1200,
    "height": 630
  }' --output card.png

When to use: Production workloads, batch generation, and any case where you don't want to manage browser infrastructure. 500 free calls/month to start. Get an API key.

Method 2: Puppeteer (Self-Hosted)

Puppeteer gives you a headless Chromium instance you control. You can render any HTML by loading it as a data URL or setting page content directly.

import puppeteer from "puppeteer";
import { writeFileSync } from "fs";

const html = `
<div style="width:1200px;height:630px;display:flex;align-items:center;
  justify-content:center;background:linear-gradient(135deg,#667eea,#764ba2);
  font-family:system-ui;color:white;font-size:48px;font-weight:bold;">
  Hello from Puppeteer
</div>
`;

const browser = await puppeteer.launch();
const page = await browser.newPage();
await page.setViewport({ width: 1200, height: 630 });
await page.setContent(html, { waitUntil: "networkidle0" });
const screenshot = await page.screenshot({ type: "png" });
writeFileSync("card.png", screenshot);
await browser.close();

When to use: You need full browser control, want to run on your own infrastructure, or have specialized rendering requirements (e.g., browser extensions, network interception).

Trade-offs: Requires Chromium (~400 MB), significant memory per instance, cold starts in serverless, and you manage the infrastructure. At scale, browser management becomes a full-time ops concern.

Method 3: Satori + Resvg (React to SVG to PNG)

Vercel's Satori converts React JSX to SVG, and resvg converts SVG to PNG. This approach avoids a browser entirely but only supports a subset of CSS (Flexbox only, no Grid).

import satori from "satori";
import { Resvg } from "@resvg/resvg-js";
import { readFileSync, writeFileSync } from "fs";

const font = readFileSync("./Inter-Bold.ttf");

const svg = await satori(
  {
    type: "div",
    props: {
      style: {
        width: 1200,
        height: 630,
        display: "flex",
        alignItems: "center",
        justifyContent: "center",
        background: "linear-gradient(135deg, #667eea, #764ba2)",
        fontFamily: "Inter",
        color: "white",
        fontSize: 48,
        fontWeight: "bold",
      },
      children: "Hello from Satori",
    },
  },
  {
    width: 1200,
    height: 630,
    fonts: [{ name: "Inter", data: font, weight: 700, style: "normal" }],
  }
);

const resvg = new Resvg(svg);
const png = resvg.render().asPng();
writeFileSync("card.png", png);

When to use: You're already in a React/Next.js ecosystem, need zero external dependencies, and your templates use only Flexbox layouts.

Trade-offs: No CSS Grid, limited CSS property support, no JavaScript execution, no web font loading (fonts must be bundled), and complex layouts may not render correctly. Great for simple cards, but not a general-purpose renderer.

Which Method Should You Choose?

Method	Setup	CSS Support	Best For
Rendex API	30 seconds	Full (Chromium)	Production, batch, AI agents
Puppeteer	10 minutes	Full (Chromium)	Self-hosted, full browser control
Satori + Resvg	5 minutes	Flexbox only	Simple cards, React ecosystem

For most production use cases, an API is the right choice. You get full CSS support, zero infrastructure, and the ability to batch hundreds of renders in a single request.

See the HTML to Image use case page for more examples, or try the free tool to render HTML without writing code.

Common Use Cases for HTML-to-Image

OG images — Generate unique social preview images for every blog post, product page, or user profile
Social cards — Branded Twitter/LinkedIn cards from HTML templates
Invoices — HTML-to-PDF invoice generation with dynamic data
Certificates — Course completion certificates with custom names and dates
Email previews — Render HTML emails as images for testing and review

Ready to start? Get a free API key (500 calls/month, no credit card) or read the API reference.

Want to see how Rendex compares to other rendering APIs? See the 2026 comparison.

How to Capture Website Screenshots with Python in 2026

Dan E — Thu, 09 Apr 2026 01:11:02 +0000

Capturing website screenshots programmatically is one of the most common automation tasks for developers. Whether you're building a link previewer, monitoring a competitor's page, or generating OG images, you need a reliable way to render a webpage and save it as an image.

This guide covers four approaches — from the fastest (an API call) to the most hands-on (a headless browser you manage yourself). Each includes working Python code you can copy and run.

Method 1: Rendex API (3 Lines of Code)

The fastest path. The Rendex Python SDK handles browser rendering on Cloudflare's edge network — no Chromium install, no memory management, no cold starts.

# pip install rendex
from rendex import Rendex
from pathlib import Path

rendex = Rendex("YOUR_API_KEY")
result = rendex.screenshot("https://example.com")

Path("screenshot.png").write_bytes(result.image)
print(f"{result.metadata.bytes_size} bytes in {result.metadata.load_time_ms}ms")

Async support is built in — ideal for batch jobs:

import asyncio
from rendex import AsyncRendex
from pathlib import Path

async def capture_many(urls: list[str]):
    async with AsyncRendex("YOUR_API_KEY") as rendex:
        for url in urls:
            result = await rendex.screenshot(url, format="webp", full_page=True)
            slug = url.replace("https://", "").replace("/", "_")
            Path(f"{slug}.webp").write_bytes(result.image)

asyncio.run(capture_many([
    "https://github.com",
    "https://news.ycombinator.com",
    "https://stripe.com",
]))

Advanced options include dark mode, ad blocking, element selectors, custom viewports, and WebP output. See the full API reference.

When to use: Production workloads, AI agent pipelines, batch processing. You get 500 free calls/month to start. Get an API key.

Method 2: Playwright

Microsoft's Playwright is the current gold standard for headless browser automation. It supports Chromium, Firefox, and WebKit, with an excellent Python API.

# pip install playwright
# python -m playwright install chromium
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    page = browser.new_page(viewport={"width": 1280, "height": 720})
    page.goto("https://example.com", wait_until="networkidle")
    page.screenshot(path="screenshot.png", full_page=True)
    browser.close()

Playwright gives you full control — you can click buttons, fill forms, wait for specific elements, and intercept network requests before capturing.

When to use: You need browser interaction before capture (login flows, cookie banners, SPAs that require clicks). You manage the infrastructure yourself.

Trade-offs: Requires a Chromium install (~400 MB), consumes significant memory per browser instance, and cold starts can be slow in serverless environments.

Method 3: Selenium

Selenium has been the go-to browser automation tool since 2004. If your team already uses it for testing, adding screenshot capture is straightforward.

# pip install selenium webdriver-manager
from selenium import webdriver
from selenium.webdriver.chrome.service import Service
from webdriver_manager.chrome import ChromeDriverManager

options = webdriver.ChromeOptions()
options.add_argument("--headless=new")
options.add_argument("--window-size=1280,720")
options.add_argument("--disable-gpu")

driver = webdriver.Chrome(
    service=Service(ChromeDriverManager().install()),
    options=options,
)
driver.get("https://example.com")
driver.save_screenshot("screenshot.png")
driver.quit()

When to use: Existing Selenium test suites where you want to add screenshot capture without introducing a new tool.

Trade-offs: Slower than Playwright, less reliable waiting mechanisms, and the WebDriver protocol adds overhead. Selenium 4+ improved significantly, but Playwright is generally preferred for new projects.

Method 4: Pyppeteer

Pyppeteer is a Python port of Puppeteer (Node.js). It uses the Chrome DevTools Protocol directly, which gives fine-grained control.

# pip install pyppeteer
import asyncio
from pyppeteer import launch

async def capture():
    browser = await launch(headless=True)
    page = await browser.newPage()
    await page.setViewport({"width": 1280, "height": 720})
    await page.goto("https://example.com", waitUntil="networkidle0")
    await page.screenshot({"path": "screenshot.png", "fullPage": True})
    await browser.close()

asyncio.run(capture())

When to use: You need DevTools Protocol access for advanced features like performance tracing or network interception, and prefer Python over Node.js.

Trade-offs: The project is less actively maintained than Playwright. Consider Playwright for new projects.

Which Method Should You Choose?

Method	Setup Time	Infra Needed	Best For
Rendex API	30 seconds	None	Production, AI agents, batch jobs
Playwright	5 minutes	Chromium install	Browser interaction before capture
Selenium	10 minutes	ChromeDriver	Existing Selenium test suites
Pyppeteer	5 minutes	Chromium install	DevTools Protocol access

For most production use cases — especially if you're building an AI agent pipeline or need screenshots at scale — an API is the right choice. You avoid managing browsers, handling memory, and dealing with cold starts.

Try the free screenshot tool to see Rendex in action without writing any code, or grab an API key and start with 500 free calls/month.

Want to see how Rendex compares to other APIs? See the 2026 comparison.