My PDF does not look like the editor
The editor is a fair preview and not a proof. Five things account for nearly every difference, in roughly the order they catch people out.
The font is not one Papers can embed
This is the common one, and the first thing to check if the whole document looks subtly wrong.
Papers ships four fonts and puts them in the PDF: Inter, Roboto, Lato and Calibri. Calibri goes in as Carlito, a lookalike with the same letter widths, so your line lengths hold. The rest of the font list, Arial and the others, are system fonts. Papers does not hold those files, so the PDF is set in whatever the renderer substitutes, and your line lengths and page breaks move with it.
New templates default to Arial, so this bites a document nobody chose a font for.
Two ways out. Set the document font to Inter, Roboto, Lato or Calibri, or upload the font you want and use that. See upload your own fonts.
You are looking at your draft, they are looking at the published version
The editor's own download button renders your draft. It reads Download as PDF unless you have picked another format from its arrow, which also offers Word, HTML, plain text and Markdown. The button stays greyed out until the editor has sample data to fill the template with.
A document sent for signature renders the version published to the environment you pick in the
signing wizard, shown beside the template as, for example, prod · v4. A document produced through
the API renders a published version too, unless the call asks for the draft.
So if the wording is old, or the change you made this morning is missing, the question is whether you published, and to which environment. See versions and publishing.
The editor has no data in it
Anything that depends on data cannot look right until there is data.
A repeating section shows one specimen row in the editor and as many rows as your data has in the document. A conditional section is a visible block in the editor and either present or absent in the document. A table of contents is a placeholder in the editor and a real list in the document.
That changes the length of the document, which changes where the pages break, which is why a two-page template arrives as three pages.
Preview with test data before you judge the layout. See preview with test data.
Page breaks are worked out at render time
The page boundaries in the editor are an approximation, drawn as you type. The real pagination happens when the document is produced, once the data is in and the fonts are resolved.
A paragraph that sits right above a break in the editor is the one that will move. If a section must start on a new page, insert a page break rather than pushing it down with empty paragraphs.
Page numbers in a header or footer are the same story: they resolve when the document is produced, so the editor shows the field and the PDF shows the number.
The asset or font changed after you published
Publishing keeps the exact images and font files the version was published with, so replacing your logo in the asset library does not change an invoice you published in March. That is deliberate.
Publish again to move the template onto the new files.
Fragments are the exception, and they work the other way: a published version follows the current content of the fragment it points at. See versions and publishing.
If none of these explain it
Download the PDF from the editor. Then start a signing request from the same template and look at the rendered document on the Fields step. If those two differ, it is the draft-versus-published question above. If they match each other but not the editor's canvas, it is the font or the pagination.
Send the editor's PDF and a screenshot of the Fields step when you report it, along with the template name and the version number. A description of a layout problem is very hard to act on; the two side by side take five minutes to compare.