Prompt AI for print- and PDF-friendly HTML (2026): the phrases that survive Ctrl+P

You ask an AI for a one-page proposal. It produces something genuinely good — sectioned layout, a pricing table, a chart, a sticky header that follows you down the page. You send the link. The client replies: "Can you send this as a PDF?" You hit Ctrl+P. The sticky header is stamped across the middle of page two. The pricing table is sliced in half by a page break. The chart is a blank rectangle. The footer repeats four times.

The content was fine. The page was built for one rendering mode — the screen — and asked at the last second to perform in a second one it never knew about. Print and screen are two different layout engines wearing the same HTML, and the model optimized for the one it could see in preview. None of this is the AI being careless. It rendered what it was shown rendering. You can fix that in the prompt, before a single line is generated — and this post is about the exact phrases that do it.

Why the screen version breaks on paper

A browser laying out a page for a 1440px monitor and the same browser laying out for an A4 sheet are running different math. Three categories of thing that work on screen have no meaning on paper:

• Viewport units. height: 100vh means "fill the screen." A printed page has no viewport, so a hero sized in vh collapses or balloons unpredictably.
• Sticky and fixed positioning. position: sticky nav follows your scroll. Paper does not scroll, so the browser stamps the sticky element onto every printed page, mid-content.
• Canvas and lazy content. A chart drawn into a <canvas> at scroll-time, or an image set to lazy-load, may simply not be painted when the print snapshot is taken — you get a blank box.

The job is to tell the model there is a second audience reading on paper, and to name the techniques that serve it. It knows them. It just defaults to the screen-only subset until the prompt widens the target.

The prompt clauses that actually change the output

Generic instructions ("make it printable") produce generic results. Specific clauses produce specific CSS. Here is the set worth pasting into the prompt verbatim, adjusting the nouns to your page:

Build this so it prints and exports to PDF cleanly, not just on screen. Include an @media print block that:

• sets @page { size: A4; margin: 18mm; }
• forces dark text on a white background for print
• applies break-inside: avoid to every card, table row, and figure so none gets split across a page break
• adds break-before: page before each major section heading
• hides the sticky nav, the share bar, and any hover-only tooltips with display: none Use static layout — no 100vh heroes, no position: sticky. Render the chart as inline SVG, not canvas, so it survives the print snapshot. Keep everything in one self-contained HTML file.

Each line maps to one of the failures above. break-inside: avoid is what keeps the pricing table whole. display: none on the sticky nav removes the stamp across page two. Inline SVG instead of canvas fills in the blank chart rectangle.

Two more clauses earn their place depending on the document:

• "Repeat table headers on each printed page" — for any long table, so a row on page three still has its column labels. The CSS is thead { display: table-header-group; }, and the model adds it on request.
• "Print the link URL after the link text" — for documents read on paper, where a bare "click here" is useless. a[href]::after { content: " (" attr(href) ")"; }.

Ask for one file, not two

There is a tempting wrong turn here: generating a separate print-only HTML. It looks tidy and it rots fast. The screen version gets edited, the print version doesn't, and within two revisions they say different things. The pricing in the PDF is last month's.

Keep it to one self-contained file with the @media print block living at the bottom of the same <style> tag. Screen and paper become two views of one source — edit the price once, both update. This also keeps the file droppable as a single upload, which matters for where it ends up living, below.

The verification pass nobody runs

The model claims it added print styles. Trust it the way you'd trust any first draft: verify. The check costs ninety seconds and catches the failures that always survive into v1.

1. Open the page in Chrome. Press Ctrl+P (Cmd+P on Mac).
2. In the preview, turn Background graphics on if your design uses colored fills, or the section bands disappear.
3. Page through the preview. Watch specifically for: a table or card split across two pages, the chart rendering blank, a sticky element stamped mid-page, and any text running off the right margin.
4. For anything broken, paste the exact symptom back to the AI — "the second table is split across pages 2 and 3; add break-inside: avoid to its rows" — not a vague "the PDF looks off."

That last point is the whole game with AI iteration. Precise symptoms get precise fixes; vague complaints get vague rewrites that break something else. You just saw the exact failure in print preview — describe that one.

If the page has data charts, run the check once on Chrome and once on Safari. Chrome's print engine is the most faithful to @page and break rules; Safari is close but occasionally clips a wide table. Knowing which engine your reader will use is worth one extra preview.

Where the page should live afterward

You now have one HTML file that renders two ways. The last question is delivery, and here the honest boundary matters.

If the document needs server logic — a form that writes to a database, per-viewer personalization, auth-gated content — that is a project, and it wants a real deploy platform like Vercel or Netlify with a backend behind it. Don't fight that with a static file.

If it is a self-contained page — a proposal, a report, a one-pager, a spec — the better shape is usually a private link, not an emailed PDF. A PDF freezes the moment you send it; revise the numbers and the old copy keeps circulating in three inboxes. A link that stays current updates in place, and the reader who wants paper still presses Ctrl+P and saves their own — from the page you already built to print cleanly. They get both shapes from one URL.

Drop the file, get an unguessable private link. Add a password if the proposal is sensitive, or a custom domain if it goes to a client who notices the URL. The page renders live in their browser; the print stylesheet you prompted for waits quietly until they need paper.

The screen-and-paper split is solved at the prompt, verified in print preview, and delivered as one link. Three steps, none of them retroactive — which is the point. Print-friendly is a thing you ask for up front, not a thing you bolt on after the client asks for the PDF.