Login Get started
Get started
Login Get started
About

About HTML to Image

We render HTML to PNG and PDF so you don't have to host headless Chrome.

HTML to Image began with a problem that kept recurring in agency work. Clients wanted dynamic Open Graph images, automated invoice graphics, and screenshot APIs, and every team kept rolling its own Puppeteer setup on Lambda. Each one came with the same broken parts: cold starts, font loading bugs, memory limits, and a custodian rotation when the original engineer left. Mike Griffiths built HTML to Image so that work would only need to happen once, and it has run as a production API ever since.

The architecture choice was deliberate. We render with real Chrome, not Satori or canvas-based shortcuts, because pixel-perfect parity with the browser matters when the same HTML and CSS already powers your product. If a layout works in your design preview, it works in the API. If it breaks in the API, it breaks in your browser. There is one rendering target to debug, not two.

We charge for renders, not seats. The free tier gives you 50 renders with no card needed. A team of 30 pays the same as a single developer at the same render volume. See pricing for the credit ladder, or the comparisons for how that comes out against the alternatives.

What's different

Renders like Chrome

The rendering engine is real Chrome. Flexbox, grid, custom properties, modern fonts and JavaScript work exactly as they do in your browser. There is no second compatibility model to maintain.

See the full feature list

Templates plus raw HTML

Use named templates for common shapes (invoices, OG images, code screenshots) or post your own HTML for full control. Mix the two as your needs grow.

Browse templates

No per-seat charges

Pricing scales with credits, not users. A team of 30 pays the same as a single developer at the same render volume. Every plan includes every feature.

See pricing

Architecture

The decisions that determine what the API does under load, and where each one is documented.

One Chrome instance per request

Renders run isolated, so a slow page on one render never blocks another and a crash never takes neighbouring jobs with it.

Output on a global CDN

Finished PNGs and PDFs land on i.html2img.com and are served from an edge network close to your users. Renders made on a paid plan are hosted permanently.

Response format

Async delivery for slow renders

Full-page captures and high-DPI exports can exceed a sensible request timeout, so we POST the finished URL to your webhook instead of holding the connection open.

webhook_url docs

A 30 second sync budget

Hot-path renders return synchronously inside 30 seconds, including any JavaScript your markup runs before paint.

Waiting for content

Who builds it

The renderer, the templates and the documentation are built by a developer who has spent two decades shipping production APIs, so support answers come from someone who knows the rendering path, not a script.

Mike Griffiths

Mike Griffiths

Software Developer · Founder

Mike has spent the last 20 years building software for all kinds of businesses, specialising in digital products and APIs. He is an expert in Laravel and a voting member on the PHP language. He writes the articles and the API documentation here, and works on the rendering service behind them.

Read more about Mike Griffiths

Trust

Uptime target

99.9 percent monthly. Renders that fail because of an outage do not consume credits.

Support response

One business day for paid plans. Reach out via the contact form.

Contact us

Billing transparency

Cancel from the dashboard at any time. No proration penalty. Downgrade allowed at the next renewal.

See pricing

Common questions

Who is behind HTML to Image?

HTML to Image is built by Mike Griffiths, a software developer with 20 years of experience building digital products and APIs. He writes the articles and the API documentation on this site as well as the rendering service itself. You can read more about him on his author page.

How reliable is HTML to Image?

The service runs to a 99.9 percent monthly uptime target, and renders that fail because of an outage do not consume credits. Each render runs on an isolated Chrome instance, so one slow or broken page cannot affect anyone else's job. Output for paid accounts is hosted permanently on a global CDN rather than expiring, and support on paid plans is answered within one business day.

Why real Chrome instead of Satori or a canvas renderer?

Because pixel-perfect parity with the browser matters when the same HTML and CSS already powers your product. Satori supports a subset of CSS, so a layout that works in your app can render differently or fail outright. With real Chrome there is one rendering target to debug rather than two. See our comparison against Satori and @vercel/og for the specifics.

Where are rendered images stored?

On the i.html2img.com CDN, served from a global edge network. Renders made on any paid plan are hosted permanently for the life of the account; free-tier renders are hosted for 7 days, and upgrading makes everything you have already rendered permanent.

What happens to the HTML I send?

It is rendered to an image on the CDN. Rendered output and associated metadata may be retained for a limited period for operational and debugging purposes, and we do not sell or rent your data to third parties. The privacy policy covers what is logged and the terms of service cover the licence you grant us to render your markup.

Can I talk to someone before committing?

Yes. The free tier gives you 50 renders with no card, so you can evaluate the API first, and the contact form reaches a real inbox for anything the docs do not answer, including yearly invoicing and volume pricing.

Render your first image

50 free renders, no credit card. Paid renders are hosted permanently.

See pricing Read the getting started guide