HTML to Image

A headless browser loads your HTML or URL, lays it out exactly as a normal browser would — applying CSS, running scripts, loading web fonts — and then captures the rendered result as an image. It is a screenshot taken by a browser with no window.

That distinction matters. This is not an approximation of how the page might look; it is the same rendering engine producing the same layout, which is why complex CSS, flexbox, grid and web fonts all come out right where simpler HTML-to-image converters distort them.

The output is an ordinary PNG or JPG, so it can go anywhere an image can go — into a social card, a document, a slide deck, or an email.

The most common production use is generating Open Graph images — the picture that appears when a link is shared on social media or in a chat app. Designing those by hand for every article does not scale; templating them in HTML and rendering to an image does.

1200×630 pixels is the standard size and is handled sensibly by essentially every platform. Build the card as an HTML template with the title, author and any artwork positioned by CSS, then render one image per article.

Two practical points: keep important content well inside the edges, because some platforms crop to their own aspect ratio, and use large type. These cards are frequently seen at a couple of hundred pixels wide in a feed, so anything below about 32 pixels in the source will be unreadable.

The renderer is a clean browser. It has no extensions, no ad blocker, no logged-in session and no access to fonts installed locally on your machine. A page that looks one way to you can legitimately render differently here, and usually the difference is informative — you are seeing what a first-time anonymous visitor sees.

Lazy loading is the most frequent cause of missing content. Images and sections configured to load when scrolled into view may not have been triggered before the capture, and data arriving from a slow API call can miss the moment entirely.

Animations and transitions are frozen wherever they happened to be. If an element fades in, the capture may catch it mid-fade — a good reason to disable animations in the CSS you render, or to design the template as a static layout in the first place.

Nearly everything on this site works inside your browser tab. Rendering a web page cannot, because it requires a full browser engine — the very thing your browser already is, but not something a page can drive on arbitrary third-party content from inside a tab.

So the URL or HTML you supply is sent to our server over an encrypted connection, rendered in a headless browser there, and the image is returned to you. Nothing is retained afterwards.

Worth noting for private content: since a URL is fetched by our server rather than by you, anything behind a login or on a private network is not reachable. That is a limitation, and also a reason this tool cannot accidentally capture something it should not.