html-to-pdfmake turns a slice of HTML into a PDFMake document definition

A converter that stops at the document definition

html-to-pdfmake exists to bridge one specific gap: PDFMake does not read HTML, it consumes a document definition object, and writing that object by hand for anything non-trivial is tedious. The library takes HTML on one side and produces the PDFMake structure on the other, so you can keep your content in markup and let the library build the tree.

The description is precise about scope: convert HTML to the PDFMake format, while maintaining basic styling and structure. The word basic is doing the work, and the README says so in two separate places.

The first caveat is that if you need to convert complex HTML, for example something produced by a rich text editor, the README suggests other options, naming an online service called Doppio, converting HTML to canvas, converting it to an image and then exporting to PDF with jsPDF. The second caveat is that other libraries may work better, and it names DOM-PDF as one example. The third is the structural one: this library has the same limitation as PDFMake, so if you need to know whether a style is supported you should check the PDFMake documentation.

That last point is the design in one sentence. html-to-pdfmake is an HTML front end for a document engine that was never a browser, and everything that means for your output follows from that.

The package is JavaScript, MIT licensed, and the repository is small: an index.js as the main entry, a browser.js bundle, an example.js and example.pdf, a docs directory, a test directory with a unit test, and a script called update-doc.js. The package.json shows the browser bundle is produced with browserify and uglifyjs from the same index.js, which is why the browser and Node entry points behave identically.

Running it in a browser with three script tags

The browser path is the shortest demonstration of the whole idea. You load PDFMake and its virtual file system fonts from a CDN, load the browser build of the library, convert a string of HTML, wrap the result as the content of a document definition, and call createPdf.

  <script src="https://cdn.jsdelivr.net/npm/pdfmake@latest/build/pdfmake.min.js"></script>
  <script src="https://cdn.jsdelivr.net/npm/pdfmake@latest/build/vfs_fonts.min.js"></script>
  <script src="https://cdn.jsdelivr.net/npm/html-to-pdfmake/browser.js"></script>

The conversion call is a single global function:

    const converted = htmlToPdfmake(html);
    const docDefinition = { content: converted };
    
    // Generate PDF
    pdfMake.createPdf(docDefinition).download('document.pdf');

The shape of that call is the whole API. htmlToPdfmake returns the content array for a document definition, and everything else about the PDF, page size, margins, headers and footers, is a PDFMake concern that you set in the document definition around it.

There is also a live demo hosted as a GitHub Pages site, which the README links from the Online Demo section. For a library this small, a browser demo that converts and renders on the same page is the fastest way to find out whether your markup is inside the supported set before you write any application code.

The Node.js path needs a window object and PDFMake initialisation

The Node.js path is where the interesting friction is, and the README documents it step by step rather than hiding it.

The install pulls in the library and a DOM implementation:

npm install html-to-pdfmake jsdom

The conversion function parses HTML, which means it needs a DOM, and in Node there is no document. The README handles this by having you create a JSDOM instance and pass its window object into the options:

const htmlToPdfmake = require('html-to-pdfmake');
// if you need to run it in a terminal console using "node", then you need the below two lines:
// const jsdom = require('jsdom');
// const { JSDOM } = jsdom;

// if you need to run it in a terminal console using "node", then you need to initiate the "window" object with the below line:
// const { window } = new JSDOM('');

// Convert HTML to PDFMake format
const html = `
  <div>
    <h1>Sample Document</h1>
    <p>This is a <strong>simple</strong> example with <em>formatted</em> text.</p>
  </div>
`;

const converted = htmlToPdfmake(html, { window });

The window option is therefore not optional in Node, which is why the example comments repeat the JSDOM setup in two places. The library itself is what the npm install gives you; jsdom is the environment you have to supply.

The other Node-specific step is PDFMake initialisation, where the vfs is assigned from the vfs_fonts module. The README flags that this line may vary depending on your version of PDFMake and points you at the PDFMake repository to see how to initialise the library for your version. That is a real upgrade hazard, and it is the part most likely to break when you bump PDFMake.

The final step is getting bytes out. The browser example downloads the file, while the Node example uses getBuffer and writes it with the fs module, which is the shape you want in a server that returns a generated PDF.

The supported element and CSS set is a closed list

The README publishes exactly what is handled, and the list is short enough to read in a minute.

Block elements are div, p, h1 to h6, the table family with thead, tbody, tfoot, tr, th and td, the ul, ol and li list elements, and pre. Inline elements are span, strong, b, em, i and s, the a tag with support for both external and internal links, sub and sup, img and svg, and br and hr. Nested elements are handled, and there is custom tag support for anything outside the list.

The CSS side is a table of fifteen properties with a support rating each. background-color has good support, as does color including opacity, and text-align and list-style-type are rated good. Border is supported including individual borders, margin including individual margins, font-style for italic, font-weight for bold, and text-decoration for underline and line-through. Font-family, text-indent and line-height are rated basic support, and height and width apply to tables and images. white-space supports nowrap, pre and break-spaces.

The rating is the useful part of that table, because it tells you where the output degrades. A property marked good will behave as you expect. A property marked basic is a simplification, and if your template depends on it you should check the result rather than assume it.

There is no float, no flexbox, no grid, no positioning, no background images and no media queries in that list. If your HTML relies on any of them, the output will not match the browser, and no amount of option tweaking will fix that, because the target engine is a paginated document layout rather than a screen.

Options that change how the conversion behaves

The htmlToPdfmake function takes an options object as its second parameter, and the defaults are documented in full, which makes it possible to reason about what you will and will not get.

defaultStyles is the largest lever. It is an object overriding the default element styling, with entries for b, strong, u, del, s, em, i, the six heading levels, a, strike, p, ul, table and th, each specifying PDFMake style properties such as fontSize, bold, margin, marginBottom, color, decoration and fillColor. The README describes it as useful for consistent document appearance, and the style keys are PDFMake's own, not CSS.

Four booleans change structure rather than appearance. tableAutoSize enables automatic table sizing based on content and CSS properties, and the README's example shows a table where a column width comes from the widest cell in that column. imagesByReference handles images by reference rather than by embedding, which matters for large assets. removeExtraBlanks removes extra whitespace, and collapseMargins collapses vertical margins between sibling blocks like CSS does, which is the option you want when the default PDFMake spacing leaves visible gaps between paragraphs.

removeTagClasses keeps HTML tag classes in the output, and the default leaves them in. ignoreStyles is a list of style properties to ignore. fontSizes is the size list used for the legacy font tag, and it defaults to a seven-element array. There is also a customTag function for handling tags outside the supported set, which is the escape hatch when you need one specific element treated specially.

The window option is required for Node.js usage, which is the one option with no default that works everywhere.

Where html-to-pdfmake is the wrong choice

The limits are structural, and the README is honest enough to point you elsewhere in the two cases where this library is most likely to be picked by mistake.

The first wrong-tool case is rich text editor output. Editor HTML is a mess of inline styles, nested spans and classes, and the README explicitly sends you to an online solution, a canvas rendering route, or an image export followed by jsPDF. That is the right advice, because the image route throws away the text and layout fidelity problem entirely and just rasterises what a browser drew.

The second is when you need more CSS than the fourteen listed properties. The README itself points at DOM-PDF as a library that may work better, and the difference in approach is that a browser-oriented renderer can be handed the whole cascade, whereas this library maps a documented subset onto a document model that has no concept of floats or positioned boxes.

The third is a licensing and packaging reality worth noting. The package.json lists its dependencies as devDependencies only, which is how the library can be installed as a runtime dependency without dragging a DOM implementation into a browser build, and jsdom and pdfmake are development-time pieces. The published package therefore has no runtime dependencies of its own, but the Node consumer has to supply both jsdom and a PDFMake build it likes, and the version compatibility of that build is on the consumer.

On maintenance, the version in package.json is 2.5.36, the most recent tag listed is v2.5.36 dated 2026-10-11, and the last push was on the same date. The release numbering shows a project in steady incremental work rather than a rewrite, and the build script, which runs the unit test, then the example, then the browser bundle and then the doc update, shows the browser bundle and the documentation page are generated artefacts rather than hand-maintained copies.

Editorial conclusion

Adopt html-to-pdfmake if you already generate PDFMake documents and want to accept simple HTML as the input format, for example a report template, a table-heavy export or user-authored markup that needs to reach a PDF. Do not adopt it for rich text editor output, for a layout that depends on the full CSS cascade, or if you need the finished PDF file rather than a document definition, since this library stops at the PDFMake structure and leaves rendering and font handling to PDFMake. Verify first that the CSS properties your template relies on are in the supported list, that your markup stays inside the supported element set, that the Node.js path works with your PDFMake version because the README notes the initialisation line varies by version, and that the tag classes and margin handling options match what you want, since defaults preserve the tag classes and do not collapse sibling margins.

Frequently asked questions

Official sources

1. Aymkdn/html-to-pdfmake on GitHub
2. License: MIT
3. Project website
4. README
5. Releases