Jetformat

HTML to PDF workflows for AI agents

A browser page is already a designed artifact. Jetformat lets an agent capture that page without rebuilding the layout in Office XML or guessing when a chart is ready.

Published · 5 min read

By Jetformat

An HTML-to-PDF agent workflow turns a web report into a PDF by calling a renderer and verifying the resulting file. The agent supplies the source, output path, and readiness conditions; the renderer supplies the browser-based capture. Jetformat HTML rendering is beta and uses a separate service.

Invoices, dashboards, statements, and customer portals often begin as HTML. The risky part is the handoff: a page may load CSS late, fetch data in JavaScript, or depend on local fonts and images. A useful renderer makes those conditions explicit and gives the agent one output path to verify.

Keep the page you already own

Jetformat accepts a local HTML file, a directory with its assets, or an HTTPS URL. The same command works for a report checked into a repository and a page already deployed behind your application.

jetformat html to-pdf page.html -o page.pdf
jetformat html to-pdf ./report-site -o report.pdf --page-size A4 --landscape
jetformat html to-pdf https://example.com/report -o report.pdf

Wait for asynchronous page content

Dashboards and charts should be captured after they are ready, not after an arbitrary click. Wait for a selector, require it to be visible, or add a short settling delay when the page needs one.

jetformat html to-pdf dashboard.html -o dashboard.pdf \
  --wait-ready ".dashboard-ready" \
  --wait-visible "svg.chart"

Inspect the output after renderer capture

The agent can prepare data, call the HTML renderer, then inspect the generated PDF with the PDF commands. Source files stay in the workflow that owns them, and the output path is concrete enough to show the user. HTML rendering is a beta and needs a separate renderer service; Office and PDF commands do not.

Read the html help or see page-based pricing.

Decide which input the renderer needs

Source Suitable input Check
Self-contained report One HTML file Content is included
Report with local assets Directory Relative CSS, images, and fonts resolve
Deployed application page URL Renderer access and authentication requirements

A URL that opens in your signed-in laptop browser is not necessarily accessible to the renderer. Do not assume that a local browser’s session or permissions are transferred. Establish the renderer’s actual access before promising a capture of a private application page.

Give the agent an observable procedure

  1. Identify the source and choose the appropriate input shape.
  2. Confirm the configured renderer endpoint and its processing boundary.
  3. Identify a ready state tied to report data, not an always-present navigation element.
  4. Run the command with a new output filename and check its exit status.
  5. Inspect the PDF’s page count and text, then open required page previews.
  6. Report the artifact and the checks actually completed, including any unresolved access or layout problem.

Separate a generated PDF from a verified report

A PDF can exist while containing a login page, an error message, or an empty dashboard. Check a report-specific title and expected content after capture. Then inspect the visual elements that text extraction cannot establish, such as charts and image proportions.

An illustrative report producing 6 PDF pages uses 6 conversion credits. Rendering 2 pages for review adds 2 credits, for 8 credits total. These example counts say nothing about completion time or whether sampling is sufficient for your report.

The HTML readiness guide covers selectors and diagnostics. MDN’s print CSS guide explains why printed output can differ from screen presentation.

Last updated