A header-and-footer line in a PDF is short text stamped at a fixed distance from the top or bottom edge of every page, and the practical approaches to adding one fall into four families: a browser-based tool, a desktop publisher, a command-line converter, and a PDF automation API. Each approach makes a different trade between effort, control, and where the document bytes travel. A one-off label on a single contract is a different task from stamping thousands of generated invoices with page numbers, so choosing the right family matters more than picking a specific app. This guide compares the four families on the same axes — where the work runs, how much typing or scripting it takes, what controls it gives you, and what it cannot do — and then walks through a concrete pass with the browser-based tool so you can judge whether it fits your situation.
The four common approaches to add a header and footer to a PDF
Most readers end up choosing between the same four families regardless of which app or service they end up using. Each family has a different shape, so comparing them on the same axes makes the trade-off obvious.
| Approach | Where the work runs | Typical effort | Best for | Main trade-off |
|---|---|---|---|---|
| Browser tool (Header Footer PDF) | Locally in the browser, no upload | Pick a file, type two text fields, click once | One-off labels, confidentiality stamps, simple page numbering | Limited to centered, single-line text and standard Helvetica |
| Desktop publisher (Acrobat, Affinity, MS Word PDF export) | Installed application on your machine | Open the file, define a template, save the export | Documents with branded headers, custom fonts, multi-line text | Requires a paid license and a per-document template |
| Command-line converter (wkhtmltopdf, headless Chrome) | Local shell or build script | Write a command with header/footer flags | HTML-to-PDF pipelines, repeatable jobs, CI runs | Limited to source formats that include HTML; not a clean retrofit for an existing PDF |
| Automation API (Power Automate, cloud PDF SDKs) | Cloud endpoint called from a workflow | Author a flow that posts the file and an HTML fragment | Bulk stamping across many generated PDFs | Sends bytes to a third-party server and adds per-call cost |
The browser row is the simplest entry point: Header Footer PDF loads the chosen file in your own browser, draws one optional header and one optional footer on each page, and saves the new bytes locally. The desktop row gives the richest typography but the heaviest setup. The command-line row is fast and scriptable, but it is really a converter from HTML, so it does not retrofit an existing PDF cleanly. The API row scales well and is the right answer when stamping is one step inside a larger document pipeline.
For a broader discussion of which family suits which job, the comparison guide for adding headers and footers to a PDF walks through the same trade-off with concrete examples.
When a browser tool is the right fit
A browser-based tool earns its place when three conditions line up at once: the document already exists as a PDF, you only need short centered text rather than a multi-line block, and you would rather not install software or send the file to a server. Confidentiality stamps, file references such as "Q3-proposal-v4.pdf", short revision names, and "Page 2 of 5" numbering are the canonical examples.
Two practical constraints tip the choice toward a browser tool. First, privacy: legal, finance, and human-resources documents often cannot leave the device, so any flow that uploads bytes is a non-starter. Second, turnaround: most readers want to stamp a single file in under a minute, which a desktop publisher cannot match without a saved template. The browser tool covers both cases because the document is loaded by the browser tab rather than a remote service.
The flip side is control. A browser tool draws the new text inside the existing page box, so any body content already near the edge can overlap the new line. If you need guaranteed clearance, you must add margin inside the source document first, or use a desktop publisher that can reflow content.
How to add a header and footer to a PDF with Header Footer PDF
The tool follows a fixed five-step flow. Each step has a single concrete decision, which keeps the workflow predictable and makes the result easy to verify.
- Open the tool and choose a local PDF. The file must be a non-empty PDF no larger than 25 MiB. Encrypted, damaged, or unsupported files produce a visible error rather than a silent pass.
- Enter header text, footer text, or both. Each field is trimmed and limited to 120 Unicode characters. Leave a field empty to skip that line entirely.
- Insert page-number tokens. Use {page} for the current one-based page number and {pages} for the total page count. A footer such as Page {page} of {pages} renders as "Page 2 of 5" on the second page of a five-page document.
- Set the font size and edge margin. Font size accepts whole values from 6 to 36 points; edge margin accepts whole values from 0 to 200 points. Header text is positioned below the top edge by the margin and requested font size; footer text begins above the bottom edge by the same margin.
- Create the file and download the result. The browser draws the expanded text on every page, embeds standard Helvetica once, and saves a new PDF whose name keeps the source filename base and adds -header-footer.pdf.
Changing any setting revokes the previous download, so a stale asynchronous job cannot replace the file created from newer settings. This protects users from grabbing the wrong output. The text-drawing call is performed by the pdf-lib page drawText API, which lets the browser-side code center each line inside the existing page box at the requested edge margin. The font embedding uses the pdf-lib StandardFonts enum, so Helvetica is embedded once and reused for every page.
What the tool changes — and what it does not
The output preserves most of the source document by design. The table below sets out, side by side, what stays and what moves.
| Aspect | Behavior |
|---|---|
| Page count | Unchanged; numbering reflects the original page count |
| Page order | Unchanged; pages remain in source order |
| Existing visible content | Unchanged; new text is drawn on top |
| Source page boxes | Unchanged |
| Filename | Keeps source base, appends -header-footer.pdf |
| Font | Standard Helvetica only, embedded once |
| Header and footer lines | One optional header line and one optional footer line, centered |
| Text length per line | Trimmed, then capped at 120 Unicode characters |
| Overflow handling | Font size reduced one point at a time down to a 6-point floor; never wrapped or silently deleted |
| Encryption, damage, or oversized files | Must be a non-empty PDF no larger than 25 MiB; failures are visible rather than bypassed |
| Encoded characters | Latin set via standard Helvetica; other writing systems or emoji fail visibly rather than substitute glyphs |
The deterministic overflow rule matters: a long footer on a narrow page keeps shrinking down to the 6-point floor. Very narrow pages or excessive margins can still leave little usable space, so inspect the result before distributing or printing it. Because the new text is drawn as additional PDF content rather than a viewer-only overlay, the stamp is permanent, but it also means any body content already near the chosen edge can overlap the stamped line.
Verify the output before you distribute or print
A quick verification pass saves more embarrassment than any other step. Open the new PDF in any reader and confirm three things in order.
First, check the visible line on page 1, the last page, and one interior page. If you used tokens, the numbers should increment by one on each page and the total should match the original page count. A footer Page {page} of {pages} on a five-page document reads "Page 1 of 5", "Page 2 of 5", through "Page 5 of 5". Replacement is deterministic and applies everywhere the exact lowercase token appears, so other brace text is left unchanged.
Second, look for overlap. The new text is drawn on top of the existing page content, so any body text, chart, or image already near the edge will collide with the stamped line. If you see overlap, raise the edge margin or shrink the font size, then re-create the file. The tool does not move body content, read the document language, or avoid logos and crop marks, so it cannot protect existing artwork from the new line.
Third, check very narrow pages. A landscape page that has been rotated, or a page with unusual trim, may leave little usable width. On those pages the tool shrinks the font down to the 6-point floor. Very narrow pages or excessive margins can still leave little usable space, so inspect the result before distributing or printing it.
For a dedicated checklist, the post-stamp verification guide walks through the same three checks and shows the failure modes to look for.