Adding a header and footer to a PDF looks like a single click, but the mistakes that follow are unusually predictable: text colliding with body content, page numbers starting on the wrong page, missing glyphs, or a file that refuses to generate at all. Every one of those failures has a specific cause, and almost all of them are visible in your inputs before you stamp. Header Footer PDF is built so the failure modes are loud, not silent — oversized files are rejected outright, text that the font cannot encode fails visibly instead of producing a corrupt label, and lines that exceed the usable page width are reduced in font size one point at a time down to a 6-point floor rather than being silently truncated. Knowing the rules that drive those behaviors is what separates a clean stamp from a PDF you have to redo. The rest of this article walks through those rules in the order you actually meet them: a pre-flight check, the exact steps to add centered header and footer lines with page tokens, the size and margin limits, the encoding boundary, and the verification pass that catches mistakes before you send the file.
Why Header and Footer Mistakes Repeat Themselves
Most header and footer errors come from the same handful of false assumptions. People expect the tool to resize the page, to support complex tokens, to embed a custom font, or to leave existing content alone and quietly "make room." The tool does none of those things, and that is by design. It draws a single optional header line and a single optional footer line on every structural page, centered horizontally using the actual measured width of standard Helvetica, with text positioned by an edge margin you choose. The source page boxes, page order, visible body content, and original page count stay exactly as they were. The new text is drawn as additional PDF content on each page rather than as a viewer-only overlay, so anything already sitting near an edge can overlap the new line.
That predictability is the whole point. Instead of silently degrading the result — stretching characters, replacing them with boxes, dropping a page from the count — the tool refuses to over-promise. If a line is too wide for the usable page width, it shrinks the font one point at a time down to a 6-point minimum. If the font cannot encode a character at all, file creation fails with a visible error. If the file is encrypted, damaged, oversized, or not actually a PDF, it is rejected with a clear message. You can read every one of those limits in the table below and plan around them, which is why the rest of this article is essentially a checklist of the boundaries the tool exposes.
Pre-flight Checklist Before You Stamp a PDF
Before you touch the controls, confirm four things. First, the source file is a non-empty PDF no larger than 25 MiB and is not password-protected. Second, you have decided whether you want a header, a footer, or both, and you have written the exact text for each line — remembering that each field is trimmed and limited to 120 Unicode characters. Third, you have a sensible font size between 6 and 36 whole points and a sensible edge margin between 0 and 200 whole points. Fourth, you have scanned the source pages for content sitting very close to the top or bottom edge, because the new line is drawn inside the existing page box and will not push anything inward.
| Setting | Accepted range | What happens at the limit |
|---|---|---|
| Source file | Non-empty PDF, up to 25 MiB | Encrypted, damaged, oversized, or non-PDF files are rejected with a visible error |
| Header / footer text length | 0–120 Unicode characters, trimmed | Anything beyond 120 characters is cut off before stamping |
| Font size | Whole points from 6 to 36 | Lines wider than the usable page width are reduced one point at a time down to 6 pt |
| Edge margin | Whole points from 0 to 200 | Header sits this far below the top edge; footer sits this far above the bottom edge |
| Page-number tokens | {page} and {pages}, lowercase only | Other brace text is left as literal text; only the exact lowercase tokens are replaced |
Add a Header and Footer to a PDF Without Mistakes
This is the exact sequence that produces a predictable result. Read it once, then run it.
- Open Header Footer PDF in your browser and confirm your file is a normal PDF under 25 MiB that opens locally.
- Choose the local PDF from your device. Wait for the tool to read the structural page count, which becomes the value used by the {pages} token.
- Type your header text in the first field, your footer text in the second, or both. If you want page numbers, include {page} for the current page and {pages} for the total. For example, a footer reading Page {page} of {pages} becomes Page 2 of 5 on the second page of a five-page document.
- Pick a font size and an edge margin. A common starting point is 10 pt text with a 36 pt (half-inch) edge margin on US Letter pages. If you expect long text, start smaller rather than larger.
- Select Add header and footer. The browser opens the source, draws the expanded text on each page, and serializes a new PDF. Nothing is uploaded to Lizely at any point.
- Download the file. Its name keeps your original filename base and adds -header-footer.pdf at the end.
- Open the downloaded PDF and skim the top and bottom of two or three pages — the first, a middle page, and the last — to confirm the line is centered, fits, and does not overlap body content.
Each step corresponds to a specific rule in the product contract, so a mistake at any step shows up the moment you try to create the file rather than after you distribute it.
Token Rules That Prevent Wrong Page Numbers
The numbering system is intentionally minimal. Two placeholders are recognized, and only when they appear in exactly lowercase form: {page} and {pages}. {page} is replaced with the current one-based page number on every page, and {pages} is replaced with the total structural page count of the source document before any text is added. Replacement is deterministic and applies everywhere the exact token appears — in the header, in the footer, or in both. Everything else inside braces is left as literal text, so {Date}, {filename}, {chapter}, or any other custom placeholder survives untouched rather than being interpreted.
Several rules follow from this. Numbering always starts at one, and the total always reflects the source — there is no starting-number offset, no Roman-numeral mode, and no separate count after insertion. If your document has a cover page and you want to skip it, that is not something the tool does for you; you would need to remove that page first using Delete PDF Pages and then stamp the result. The same simple rule applies to odd/even pages, section-specific numbering, and Bates numbering: none of those are supported, by design, so the output stays easy to verify against the source.
Size, Margin, and Overflow: What the Tool Adjusts and What It Doesn't
Font size, edge margin, and overflow interact in a specific way. Font size is the actual rendered point size, edge margin is measured in points from the top or bottom edge of the page, and the text is centered horizontally from the real text width measured with the embedded standard Helvetica font. Both lines are drawn inside the existing page box, so a margin of 0 puts the line flush with the edge and a margin of 200 pushes it well inside the page on most documents.
Edge margin is a vertical setting only: the header sits that distance below the top edge, and the footer sits that distance above the bottom edge. The horizontal centering uses the real measured width of the embedded standard Helvetica font, with no horizontal margin subtracted from the page width. At 10 pt Helvetica, a typical short label fits comfortably; a 110-character line, however, will trip the overflow behavior and be reduced one point at a time until it either fits or hits the 6-point floor. The tool does not stretch, wrap, or remove characters to force a fit — it only reduces the font size. If a label still does not fit at 6 pt, the file is still generated, but the line will sit tight against or past the edge margin; the safe response is to shorten the text or shrink the margin.
Standard Helvetica supports a practical Latin character set but not every writing system or emoji. The tool checks encoding before drawing: if Helvetica cannot represent a glyph in your text, file creation fails with a visible error rather than producing missing-glyph boxes. For multilingual branding, custom fonts, or precise typography, use a desktop publishing application that can embed the required licensed font.
Edge Cases That Cause the Tool to Fail Outright
Several inputs trigger a visible error instead of a partial result. Password-protected or encrypted PDFs are rejected — the tool cannot unlock a file whose password you have not supplied, and there is no silent bypass. Files larger than 25 MiB are rejected before any drawing work starts. Empty files and files that are not actually PDFs (for example a document renamed to .pdf) are rejected for the same reason. Damaged PDFs that cannot be parsed produce a visible parse error. None of these are recoverable inside the tool; the fix is at the source, not in the controls.
Async behavior is another quiet source of mistakes. Changing any setting — text, font size, margin, or file — revokes the previous download so a stale result cannot be mistaken for the current configuration. If you previously downloaded a file, then edited a field, the prior file is no longer linked from the page; you must create and download the file again. This is intentional: it prevents distributing an old version with new label text.
Verify the Output Before You Send the File
The last layer of mistake prevention is verification. Open the downloaded PDF in your normal viewer at 100% zoom and check the first page, a middle page, and the last page. Confirm the line is centered, the margin looks consistent, and no body content overlaps. If your text contains tokens, confirm {page} increments correctly (1, 2, 3, …) and {pages} equals the source page count. If you intend to print, do a quick print preview on one or two pages — many of the visible-overlap problems only show up at print scale, especially on narrow pages where the margin consumes most of the usable height.
For more on how tokens, margins, and limits are enforced, see the PDF Header and Footer Stamp: Tokens, Margins, and Limits guide. For the technical implementation, the text drawing uses PDFPage.drawText from pdf-lib, with text measured using standard Helvetica; both behaviors are visible in the open-source API documentation.
Related reading: Check the Result After Adding a Header and Footer to PDF.