Free Online HTML to PNG Screenshot Generator

Modern colour functions stop the whole capture. html2canvas 1.4.1 parses colours itself and only understands the older syntaxes. A single oklch(), oklab(), color-mix() or color() anywhere in the tree, including in a stylesheet you did not write, makes it throw unsupported color function and abandon everything. Since these are now common in frameworks and in default stylesheets, this page walks the computed styles before capturing and rewrites every such declaration into a plain rgb(). It tells you how many it changed.

Resolving a colour needs a canvas, not a property read. The obvious approach, setting fillStyle to the value and reading it back, returns the same string you put in for anything the canvas does not recognise, so it tells you nothing. What does work is applying the value to a throwaway element, letting the browser compute it, then painting one pixel and reading it with getImageData from a one by one canvas. That comes back as real numbers because the browser has done the conversion in the only place it cannot fake it.

A color-mix() built from a var() cannot be resolved in advance. The variable’s value depends on where in the tree the declaration lands, and the mix has to happen after that. There is no honest way to pre-compute it, so the whole declaration is dropped rather than guessed at, and the count of dropped declarations is reported. Those elements render with whatever they inherit instead.

srcset has to be removed, not just ignored. Every image must become a data: URL before capture, or the canvas is tainted and cannot be exported at all. But if a srcset attribute survives, the browser is free to pick a candidate from it rather than the src that was inlined, and that candidate is a remote URL, and the canvas is tainted again. So srcset and sizes are stripped entirely from every image before anything is drawn.

About the HTML Screenshot Generator

Turning HTML into an image is the sort of thing that should be easy and is not. The proper answer is a headless browser, which means installing one, keeping it updated and giving it somewhere to run. For a one-off image of a card, an invoice or a chart, that is a great deal of machinery. html2canvas takes a different route: it reads the page that your own browser has already laid out and redraws it onto a canvas. The layout is therefore genuinely correct, because a real browser did it, and only the painting is an approximation.

This page gives that library a controlled box to work in. Your markup goes into an element of a fixed width, your CSS is applied to it, and that element is what gets captured, so the viewport width is a real constraint rather than a hint. The URL mode reuses the same endpoint the other two server-touching tools on this site use, fetching the page, its same-site stylesheets and its images, and inlining all of them before anything is drawn.

Most of the work here is not the capture but the preparation, and all of it came from building the PDF version of this tool first. One modern colour function anywhere aborts the whole render, so the computed styles have to be walked and rewritten. Resolving a colour reliably means painting a pixel and reading it back, because reading the property gives you your own string. A mix built from a variable cannot be resolved at all and has to be dropped honestly rather than guessed. And every image has to be inlined with its srcset stripped, or the canvas is tainted and the export silently fails. The log after each capture exists because those fixes change your page, and you should be told what changed.