Template bugs have a particular cruelty to them: they do not show up on the document you designed. They show up on document number four hundred, the one with the unusually long company name, generated at 2am by a job nobody was watching.
The canvas said it fit. The PDF disagreed. By the time anyone looks, the file is already attached to an email.
Where the disagreement comes from
Text has a rendered height, and that height depends on the font, the size, the line breaking, and the actual string. Change the string and the height changes. A box that comfortably held "Acme Ltd" does not necessarily hold "Acme Manufacturing and Logistics Private Limited".
If the browser and the PDF engine measure that height slightly differently — and they will, being different pieces of software — then the canvas can show text sitting neatly inside its box while the generator quietly clips it.
Asking the engine that actually renders
The fix is not to make the browser guess better. It is to stop guessing.
When you save, we run a measurement pass through the same engine that produces your PDFs and ask it, for each text element, how tall the content will actually be. Then we compare that against the box you drew. If the measured height is larger, you get a warning naming the element and by how much it overflows.
It is the renderer's own answer, not an approximation of it. That is the property worth having: the thing measuring is the thing that will eventually be right.
Deliberately a warning, not a block
We surface these and let you save anyway.
That is a real design decision and it could have gone the other way. The argument for blocking is obvious — do not let a broken template ship. The argument against is that "broken" is not always true. A box that overflows with today's placeholder may be perfectly sized for real data. A designer mid-edit does not want a save refused because a paragraph is temporarily too long.
So the tool says what it found and gets out of the way. You either grow the box, which is almost always right, or you look at it, decide it is fine, and carry on.
A tool that blocks on a rule that is right 80% of the time trains people to work around it. A tool that tells you what it noticed keeps being useful.
What it covers, and what it does not
This is where we should be precise, because a safety net you misjudge the size of is worse than one you know is small.
Covered today: text elements — text blocks, paragraphs, headers, footers and floating text — plus table row heights.
Not covered yet: lists, images, and shapes. A list is text-bearing and can absolutely overflow its box, and right now it is not measured, so no warning appears. Nested content inside a table cell or a list item is not measured either — the check runs over top-level elements.
So: if the warning fires, believe it. If it does not fire, that means no text or table element overflowed, which is not the same as "everything fits". Give a list-heavy template a look with realistic data before you wire it into something automated.
We would rather write that paragraph than let you infer a guarantee we do not offer.
Getting the most out of it
Test with your worst data, not your neatest. The longest customer name, the invoice with forty line items, the address with a second line. Those are the documents that break, and they are the ones nobody puts in a demo.
Leave text boxes a little larger than they look like they need. Vertical slack costs nothing on a page that is mostly whitespace and absorbs the string you did not anticipate.
Fix the warning rather than accepting it, unless you have a specific reason. An accepted overflow is a decision that lives only in your head; the next person to open the template sees a warning with no explanation and has to work out whether it matters.
The goal is not zero warnings. It is that every remaining warning is one somebody looked at on purpose.