DEV Community: Paperwork Kit

Testing that an HTML page prints to exactly one PDF page, headless, with Chrome and a regex

Paperwork Kit — Tue, 03 Nov 2026 07:21:55 +0000

I ship small HTML tools that print to a one-page PDF: receipts, notices, checklists. The bug that keeps coming back is not in the JavaScript. It is a header 2 px too tall that pushes the signature line onto page two, and nobody notices until a customer prints it. Here is the headless test I now run on every file before it goes out. It needs Chrome and Node, nothing else.

1. Render the PDF without a window

Chrome can print a local file to PDF from the command line:

chrome --headless=new --disable-gpu --no-pdf-header-footer \
  --print-to-pdf=out.pdf --virtual-time-budget=3000 \
  "file:///C:/work/rent-receipt.html?test=1"

--virtual-time-budget lets timers and localStorage restores run before the print. The ?test=1 query string is read by the page: when present, a tiny script fills every field with realistic values (long names, a 12-digit amount, a two-line address) so the layout is tested under load, not with empty inputs.

if (location.search.includes('test=1')) {
  const demo = { landlord: 'Marguerite de la Fontaine-Lacroix', tenant: 'Jonathan Christopher Alexander',
    address: '1234 Longest Street Name You Can Think Of, Apartment 12B', rent: '12345678.90' };
  for (const [k, v] of Object.entries(demo)) { const el = document.getElementById(k); if (el) { el.value = v; el.dispatchEvent(new Event('input')); } }
}

2. Count the pages

A PDF page object contains /Type /Page (without the trailing s of /Pages). A regex is enough; no library:

import { readFileSync } from 'node:fs';
const pdf = readFileSync('out.pdf', 'latin1');
const pages = (pdf.match(/\/Type\s*\/Page[^s]/g) || []).length;
if (pages !== 1) { console.error(`expected 1 page, got ${pages}`); process.exit(1); }

Compressed object streams (PDF 1.5+) can hide page objects from this regex. Chrome's output has not hidden them in my files, but if the count ever comes back as 0, fall back to pdf-lib or pdfinfo.

3. Check what actually printed

Page count says nothing about content. The second check renders the page with --dump-dom under the print media and reads a <pre id="RESULT"> block that the page fills with the values it displays:

chrome --headless=new --dump-dom --virtual-time-budget=3000 \
  "file:///C:/work/rent-receipt.html?test=1" > dom.html

Then a few includes() assertions on the text: the amount in words is present, the month is the current month (my January bug, see the previous post), the receipt number incremented. Take the last <pre id="RESULT"> in the document, not the first: the first one is the test script's own source.

4. Hide the harness from the print

A <pre> block injected for testing adds height and triggers the very overflow you are testing for. Put it under .noprint:

@media print { .noprint, #RESULT { display: none !important; } }

5. Run it on every file

for f in produits/*.html; do node test-print.mjs "$f" || exit 1; done

Ten tools, about twelve seconds. The script has caught a two-page overflow three times since I wrote it, each time from a change that looked harmless (a longer label, a second address line).

Two things I have not solved

Letter vs A4: I test both with @page { size: Letter } and size: A4 toggled by a query string, but Chrome's headless margins differ slightly from the print dialog. The 18 mm margin leaves enough slack so far.
Mobile Safari ignores part of @page; I have no headless equivalent for it.

The tools this test protects: the free rent receipt generator at https://paperworkkit.itch.io/rent-receipt-free (runs in the browser), and the paid Landlord Paperwork Kit, six offline documents with the same engine: https://paperworkkit.itch.io/landlord-paperwork-kit

If you count PDF pages differently, or have a reliable way to test Safari printing without a device farm, I would like to know.

A rent receipt generator in one HTML file: print CSS, localStorage, and the bug I shipped

Paperwork Kit — Sat, 31 Oct 2026 07:36:46 +0000

I needed a rent receipt generator for a small landlord. The obvious answer was a SaaS: sign up, store tenants in a database, email PDFs. I built the opposite: one HTML file, no server, no build step, that prints a one-page PDF from the browser. Here is what that constraint taught me, and where it breaks.

The constraint

One file. Open it from disk or from a static host, it works the same.
No external scripts, no fonts from a CDN, no analytics. The file must work offline in 2036.
State survives a reload, but never leaves the machine.
The printed result must be a clean Letter or A4 page, not a screenshot of a web form.

Three things that did most of the work

1. Two layouts in one document, switched by @media print.

The page has a form on the left and the document on the right. The print stylesheet hides everything with a .noprint class and lets the document fill the page:

@page { size: auto; margin: 18mm; }
@media print {
  .noprint { display: none !important; }
  body { background: #fff; }
  .sheet { box-shadow: none; width: auto; margin: 0; }
}

"Save as PDF" in Chrome, Edge, Firefox and Safari all go through the same path, so the user never installs anything. The trap: a header that is 2 px too tall pushes a signature line onto page two. I now test every tool headless with --print-to-pdf and count the pages in the output (a regex on /Type /Page is enough).

2. localStorage as the whole backend.

Every input has an id. On input, the tool serialises the fields to one JSON blob under a versioned key; on load, it restores them. That is the entire persistence layer:

const FIELDS = ["landlord","tenant","address","month","year","rent"];
function save(){ const o={}; for(const f of FIELDS) o[f]=$(f).value;
  localStorage.setItem("rentreceipt.v1", JSON.stringify(o)); }
function load(){ const o=JSON.parse(localStorage.getItem("rentreceipt.v1")||"{}");
  for(const f of FIELDS) if(o[f]!==undefined) $(f).value=o[f]; }

Next month the landlord clicks "Next month": the period and receipt number increment, everything else stays. A bug I shipped: I set the default month from new Date() after calling load(), so a restored empty value won the race and every receipt defaulted to January. Set defaults first, then restore.

3. Amount in words, without a library.

A receipt should say "$1,200.00 (one thousand two hundred dollars)". A number-to-words function is about forty lines for English, and the cents are the tricky part (round first, split, then format). I kept it per-currency rather than generic because "euros and cents" and "pounds and pence" need their own words anyway.

Where the single-file approach breaks

No email delivery. The user attaches the PDF themselves.
No multi-device sync. The data lives in one browser profile; clearing site data erases it. I say so on the page.
No updates in place. If I fix a bug, people who downloaded v1.0 keep v1.0. The free version is hosted so it always gets the fix; the paid files are versioned zips.
Mobile Safari prints oddly: print preview works, but @page margins are partially ignored.

Result

The free version is hosted here: https://paperworkkit.netlify.app/en/ (and as a browser-playable tool on itch.io: https://paperworkkit.itch.io/rent-receipt-free). The same engine runs five more documents a small landlord needs (late notice, deposit return, rent increase, inspection checklist, annual statement), sold as a kit of offline files: https://paperworkkit.itch.io/landlord-paperwork-kit

If you have built single-file tools and solved the mobile print problem, I would like to hear how.