TL;DR
A webpage has no pages. It's one continuous column of unknown length. A PDF has pages. Something has to decide where one ends and the next begins, and that something is Chrome's print engine reading the page's CSS — which the site's authors almost certainly never tested.
That's why your invoice table splits mid-row, your section heading ends up alone at the bottom of a sheet, and your chart gets sliced in half.
Four levers actually change where the breaks land, and they're all in Convert: Web to PDF:
- Scale — shrink content so a block fits inside one sheet instead of straddling two.
- Paper size — A3 or Ledger gives a wide table a sheet it actually fits on.
- Orientation — landscape fixes horizontal overflow, which is often the real cause of a bad vertical break.
- Single Page Mode — stop paginating entirely and emit one tall page.
And one lever that removes the problem instead of solving it: Remove Elements, to delete the sticky header that's been eating four lines off the top of every sheet.
Why the break lands where it lands
When Chrome converts a rendered page to PDF, it walks the layout top to bottom, filling a sheet until the next box won't fit, then starts a new sheet. It respects a handful of CSS properties if the page happens to set them:
| CSS property | What it asks for | How often sites set it |
|---|---|---|
break-inside: avoid | Don't split this element across sheets | Rare |
break-before: page | Always start a new sheet here | Rare |
break-after: avoid | Keep the next block with this one | Very rare |
orphans / widows | Minimum lines kept together | Almost never |
The honest summary: most websites set none of these. Print CSS is the least-maintained stylesheet on the internet. A site that has one usually inherited it from a template in 2016 and nobody has opened a print preview since.
So the break lands wherever the sheet happens to run out. Not a bug in the converter — an absence of instructions in the page.
The three failures people actually hit
The mid-row table split. A row is a box. If the box starts 2cm from the bottom of an A4 sheet and is 3cm tall, it splits. You get the product name on page 3 and the price on page 4.
The orphaned heading. "Section 4: Payment Terms" lands as the last line on a sheet, with its paragraph starting on the next one. Nothing is missing, but the document reads badly and looks unreviewed — which matters if you're sending it to a client or filing it.
The sliced chart. A canvas or SVG chart is one indivisible box to your eye but just a block to the layout engine. It gets cut like anything else.
Lever 1: Scale — the one people skip
Scale is the highest-leverage setting and the least used, because it sounds like it only affects font size. It doesn't. It changes how much content fits per sheet, which changes every break position downstream.
The rule of thumb: if a block is splitting and it's nearly fitting, drop the scale by 10% and re-preview. A table that's 3cm too tall at 100% fits comfortably at 90%.
Where it stops working: below about 70%, body text on a dense page starts getting genuinely hard to read on paper, and you're trading one problem for another. If you need to go below 70%, the answer is a bigger sheet, not smaller type.
A useful workflow: preview at 100%, note which block is breaking badly, then step down in 5% increments and watch that specific block. You'll usually find the threshold within two tries.
Lever 2: Paper size — for the ones that will never fit
Convert: Web to PDF supports paper sizes up to A3 and Ledger. This exists for exactly one reason: some content is not A4-shaped and never will be.
| Content | Sheet that usually works |
|---|---|
| Article, blog post, documentation | A4 / Letter |
| Invoice, receipt, order confirmation | A4 / Letter |
| 8–12 column table | A4 landscape or A3 portrait |
| Analytics dashboard, Gantt chart | A3 or Ledger landscape |
| Wide financial model, pivot output | Ledger landscape |
A3 is 297 × 420mm — roughly double A4. Ledger (11 × 17in) is the US equivalent. Both open fine in any PDF reader on any device; the size only matters if someone physically prints it, and most of these documents never get printed.
The counterintuitive part: going up a paper size often produces fewer awkward breaks than scaling down, because you're giving blocks room rather than compressing them. If a table splits at A4/100%, try A3/100% before you try A4/80%.
Lever 3: Orientation — when the vertical break is a horizontal problem
This one is worth internalising because it's a genuine misdiagnosis trap.
A wide table on a portrait sheet does one of two things depending on the site's CSS: it overflows off the right edge (you lose columns silently), or it wraps — each row becoming two or three stacked lines. Wrapped rows are tall rows, and tall rows split.
So the mid-row break you're seeing isn't a vertical-space problem at all. It's a horizontal one. Switch to landscape, the rows stop wrapping, they get short, and they stop splitting. Nothing about the vertical settings changed.
Diagnostic: if your rows look one-line on screen but two-or-three-line in the PDF preview, you have a width problem. Fix width first, then look at breaks again.
We cover the specific "my wide table gets cut off on the right edge" case in the customization section of the Convert: Web to PDF FAQ.
Lever 4: Single Page Mode — delete the problem
Single Page Mode emits one continuous page as tall as the content, instead of slicing it into sheets. No sheets means no breaks means no mid-row splits, no orphaned headings, no sliced charts.
When this is the right call:
- Chat logs, Slack threads, comment chains — anything conversational where a page boundary is meaningless
- Long single-column articles that will only ever be read on screen
- Timelines, changelogs, activity feeds
- Anything you're archiving as evidence, where fidelity to what was on screen matters more than print layout
When it's the wrong call:
- Anything that will be physically printed
- Anything going into a document management system with page-count expectations
- Court filings, regulatory submissions, or anything with a formal page-numbering requirement
- Very long pages — a 200-screen page becomes a single enormous page that some older PDF readers handle badly
The extended FAQ covers the mechanics of emitting one long page instead of A4 sheets.
The sticky-header tax
Here's a break problem with a different cause and a different fix.
Modern sites pin a header, a cookie bar, a "back to top" button, or a chat widget to the viewport. During conversion, a pinned element can be re-drawn at the top of every single sheet — so a 90mm nav bar costs you 90mm off every page of a 20-page PDF. That's not just ugly; it pushes content down, which moves every break, which creates splits that wouldn't otherwise exist.
Two fixes, in order of preference:
- Hide sticky elements — the built-in toggle, which handles the common cases.
- Remove Elements — click the offending header, chat widget, or floating bar and delete it before converting. Deletions are undoable if you take out too much.
Removing a 90mm header from a 20-sheet document doesn't just clean it up — it can drop the whole thing to 17 sheets, and the three sheets you saved were pure furniture.
Article Mode: the nuclear option for break problems
Article Mode runs the page through Readability — the same engine behind Firefox's Reader View — and rebuilds it as a clean single column: headline, byline, body text, images. Every sidebar, nav, ad slot, related-posts grid, and floating widget is gone.
Break behaviour becomes boringly predictable, because there's nothing complicated left to break. One column of text and images paginates the way a Word document does.
The caveat we always give: Readability is tuned for articles. On a code-heavy page it can drop <pre> blocks, and on a dashboard or app UI it either produces nothing useful or grabs the wrong region entirely. For documentation with code samples, stay in default mode and use Remove Elements instead. The modes section of the FAQ covers when Article Mode picks the wrong content.
A decision table
| Symptom | First thing to try | If that fails |
|---|---|---|
| Table splits mid-row | Landscape | A3 + scale 90% |
| Heading orphaned at page bottom | Scale −10% | Single Page Mode |
| Chart sliced in half | Scale −15% | A3 landscape |
| Columns missing off the right edge | Landscape | A3/Ledger landscape |
| Huge margin of dead space at top of every page | Hide sticky elements | Remove Elements on the header |
| Everything breaks badly, page is article-shaped | Article Mode | — |
| Everything breaks badly, page is app-shaped | Remove Elements, then scale | Single Page Mode |
How the other tools handle this
Chrome's built-in Print to PDF gives you scale, paper size, and margins — the same underlying engine, which is why the same break problems appear. What it doesn't give you is element removal, so the sticky-header tax is unavoidable, and it has no single-page option at all. It also won't pre-load lazy images, so on long pages you're often fixing breaks in a document that's missing half its content anyway.
PrintFriendly does remove elements and is genuinely good at article-shaped pages. It's a hosted service, which means the page content goes to their server — a non-starter for anything behind a login, and worth knowing about even for public pages.
PDFCrowd and other URL-based converters fetch the URL themselves from their own infrastructure. They never see the page as you see it: no session, no personalisation, no logged-in state. For a public marketing page that's fine. For an invoice in your account dashboard, they'll get a login screen.
Adobe Acrobat's web capture is competent and produces good page breaks, and it's part of a subscription. If you already pay for Acrobat, it's a reasonable tool. If you're paying for Acrobat for this, that's an expensive way to buy a print dialog.
GoFullPage and screenshot-based capture tools sidestep page breaks by producing one tall image. That's a real solution to the break problem and a bad solution to everything else — the output is an image, so nothing is selectable, searchable, or clickable, and a screen reader gets nothing.
Convert: Web to PDF runs entirely in your browser using Chrome's own print engine. The PDF has selectable text and working links, nothing is uploaded, and it works on pages you're logged into — because it's converting the page already rendered in your tab.
Frequently asked questions
Why does my table split across two pages in the PDF?
Because a table row is a layout box, and if the box doesn't fit in the space remaining on the sheet, the print engine splits it. Most websites don't set break-inside: avoid on their rows, so nothing tells Chrome to keep them together. Fix it by reducing scale so more fits per sheet, switching to landscape so rows stop wrapping to multiple lines, or moving up to A3/Ledger.
Can I manually choose where the page breaks go?
Not by placing markers, no — the break positions come from the page's own CSS plus your paper size, scale, and orientation. In practice you get indirect control: adjust those three settings and watch the preview, or use Remove Elements to delete blocks above the problem area, which shifts everything after it. For full control, Single Page Mode removes breaks entirely.
Why is there a big empty gap at the top of every page?
Almost always a sticky or fixed-position element — a nav bar, cookie banner, or chat widget — being re-drawn at the top of each sheet. Turn on "Hide sticky elements", or use Remove Elements to delete it before converting.
What paper size should I use for a wide table?
Try A4 landscape first; it solves most 6–8 column tables. For 10+ columns or a dashboard, use A3 or Ledger in landscape. Going up a paper size usually produces cleaner breaks than scaling down, because you're giving content room rather than compressing it.
Does Single Page Mode work for very long pages?
It works, but be sensible about it. A page that's 30 or 40 screens deep produces a tall single page that any modern PDF reader handles fine. Something in the hundreds of screens produces a very large single page that older readers and some mobile viewers render slowly. If the document will be printed or filed anywhere formal, use normal pagination instead.
Will fixing page breaks change the text or images in the PDF?
No. Scale, paper size, and orientation change layout only — the text stays selectable and the links stay clickable, because the PDF is rendered by Chrome's print engine rather than captured as an image. Remove Elements does change content, by design: it deletes what you click before converting.
Does any of this send my page to a server?
No. Conversion happens entirely inside your browser. The page never leaves your machine, which is why this works on login-protected pages like an account dashboard or an internal tool.
Bottom line
Page breaks in a web-to-PDF conversion aren't random and they aren't a defect — they're the consequence of paginating a document that was never designed to have pages. The site didn't tell the print engine what to keep together, so it guessed.
You have four ways to change the guess: scale, paper size, orientation, and Single Page Mode. Plus one way to remove the problem's most common cause, which is deleting the sticky header that's been silently taxing every sheet.
Start with orientation if a table is involved — the vertical break is usually a horizontal problem wearing a disguise.
Convert: Web to PDF is free, has no watermarks, and runs entirely on your machine. If you want the full reference, the 117-question FAQ goes deeper on layout, modes, and troubleshooting.
Spending your evenings scrolling streaming catalogues instead of watching anything? CineMan AI picks something and gets out of the way.