Print.js: the print dialog call every web project ends up writing by hand

A tiny library whose README is mostly a pointer elsewhere

The README opens with one line: a tiny javascript library to help printing from the web. Everything after that is installation, contribution instructions and licence text, with a single line in between that says documentation and examples are at printjs.crabbly.com.

That is an honest arrangement rather than a thin one. The repository is the code, and printjs.crabbly.com is the manual, including a CDN section. It means evaluating the library takes two steps: read the repository for what it actually contains, then read the site for how you are meant to call it.

What the repository contains is small and legible. The tree is `.babelrc`, `karma.conf.js`, `webpack.config.js`, `bower.json`, `package.json`, a `src/` directory and a `test/` directory. There is no framework, no plugin system and no build output committed under version control beyond what `dist/print.js` implies as the published entry point. The project is MIT licensed and its homepage in `package.json` is printjs.crabbly.com.

Installing from npm, yarn, a release download or the CDN

Four routes are documented, and the README is explicit about each. From GitHub releases you can download the latest version, or you can take the Print.js CDN build listed on the documentation page.

The npm route is the ordinary one:

npm install print-js --save

and yarn is documented alongside it:

yarn add print-js

Either way you import a single default export:

import printJS from 'print-js'

The published package is named `print-js`, while the repository, the library and the identifier are all `Print.js`, with the capital P and the capital J. The `package.json` sets `main` to `dist/print.js` and `types` to `src/index.d.ts`, so the TypeScript definitions ship from source rather than from the build output. If you are on a modern bundler, the import above is the whole integration.

What the release history says about the design

The GitHub releases are sparse, which is itself informative. v1.6.0, published on 2021-02-17, adds support for HTML elements as the printable param, described as an alternate option to an element id. v1.5.0, from 2020-10-10, fixes a base64 issue when a param value is false, fixes problems with the `onPrintDialogClose` callback, removes the print iframe from the DOM once the job completes, and improves the browser incompatibility check for Internet Explorer while deprecating the `onOpen` property.

v1.4.0, from 2020-09-26, put the CSS spinner back into the available styles as optional, and fixed a missing font-size property in style processing.

Read together, those three releases describe a library that works by building a print document in a hidden iframe and then handing it to the browser's print dialog. The iframe lifecycle is the source of two of those fixes: it has to be removed afterwards, and it is where the spinner and style processing happen. The `onOpen` and `onPrintDialogClose` properties are the hooks for knowing when that hidden document is ready and when the user has closed the dialog, which is the part browsers do not tell you on their own.

The `version` field in `package.json` still reads `1.6.0`, matching the newest release, even though the last push was on 2026-07-24.

The supported print shapes, as far as the repository reveals them

The README does not document the function signature, so what can be established comes from the release notes and the source layout. Three printable targets appear across those sources: the whole page, a single element referenced by id, and, since v1.6.0, an HTML element passed directly.

Alongside the target there is a styles parameter. v1.4.0 mentions available styles and an optional CSS spinner that had been removed and was reinstated, which implies the library ships a small set of named styles you apply rather than an arbitrary stylesheet you author. The v1.4.0 fix to a missing font-size property in style processing is a warning about that path: styles were being transformed, and the transformation had a gap.

Parameters are where the library is most fragile. The v1.5.0 fix for a base64 value that was `false` suggests parameters are passed through a mechanism that treats falsy values as absent, which is exactly the class of bug that bites when you send an image and it happens to be empty. Treat falsy parameter values as untested territory.

For the exact option names and their defaults, the documentation site is the only place they are written down.

A dev environment built on Karma, Jasmine and webpack

The contribution section is more detailed than the usage section, and it describes a 2020 era toolchain. The library follows the JavaScript Standard style guide, and the README notes that running the tests also checks for style issues. Automated tests are written with Jasmine and run through Karma.

Setting up a dev environment takes two commands:

npm install
npm run watch

and the automated tests are:

npm run test

Manual testing is separate, and the README is specific about what it does:

npm start

That serves `test/manual/test.html` and opens the manual page at `http://localhost:8080/test/manual` in your default browser. The manual fixture is more useful to a reader than the unit tests are, because it is the closest thing in the repository to a gallery of working print examples.

The dependency list confirms the vintage: webpack at `4.44.1`, `node-sass` at `4.14.1`, Karma at `5.2.1`, and `karma-phantomjs-launcher` still in devDependencies. `node-sass` in particular will fail to install on current Node versions, which is the practical obstacle anyone cloning this repository will hit first. Consumers who install the published package do not pay that cost.

Where Print.js stops and the print dialog takes over

The library's scope ends at the browser's print dialog. It does not generate a PDF file, it does not lay out a page for paper, and it does not tell you what the user chose in the dialog. Whatever comes after that, saving to PDF, choosing a printer, changing margins, is the operating system's business.

This matters when you compare options. Libraries built on PDFKit or on a headless browser produce a file you can email or attach, which is a different requirement from printing what the user already sees. Print.js is for the case where the user has a printer or a print-to-PDF dialog and wants the right content to appear in it.

The comparison with the platform is worth making plainly. `window.print()` prints the current document and nothing else, which is why teams write the hidden-iframe trick themselves. Print.js is that trick with a spinner, a few named styles, and callbacks around the dialog, packaged and MIT licensed. The value it adds is real but bounded, and you can read the whole of `src/` in a sitting.

Where it is genuinely behind is documentation. The repository sends you elsewhere for the reference, and there is no changelog beyond three GitHub releases, the newest from 2021.

Editorial conclusion

Print.js is a reasonable answer to a small problem: browsers give you one print call and no way to control what appears in the print dialog. The library adds the two things people actually need, a target and a stylesheet, and it does so in a few hundred lines of MIT licensed code you could also write yourself in an afternoon. It is a poor fit if you need PDF generation, since the browser print dialog and the PDF are two different problems, and a bad fit if you need current documentation, since the reference lives on printjs.crabbly.com rather than in the repository. Start with the single call signature, and read `test/manual/test.html` if you need to see what the supported print shapes look like.

Frequently asked questions

Official sources

1. crabbly/Print.js on GitHub
2. Issues
3. License: MIT
4. README
5. Releases