The right approach to add a header and footer to a PDF is the one that fits four constraints: how much typography control you need, whether the file is allowed to leave your device, how big the file is, and whether you need features beyond centered text such as multi-line content, custom fonts, or section-aware numbering. For straightforward centered labels with optional page numbers, a browser-based tool that runs locally covers the case in three actions: pick a PDF no larger than 25 MiB, type the header or footer text using {page} and {pages} tokens if you need numbering, and choose a font size between 6 and 36 points plus an edge margin between 0 and 200 points. For multilingual text, custom fonts, multi-line labels, dynamic dates, or PDFs that need to meet archival standards, a desktop publishing app is the safer choice because it can embed a licensed font and adjust the page box. This guide explains how to pick the right approach for your situation, then walks through the exact steps for the browser-based path using Header Footer PDF.
What Decides the Right Approach
Most readers reach this question because they have a specific PDF in hand and a specific label they want to show on every page. The wrong tool for that job wastes time and can quietly damage the output. Choosing the right approach means matching the method to four things: control over typography, data location, file size, and label complexity.
Typography control covers whether you need a specific font, weight, or script support. Data location covers whether the file can be uploaded to a remote server or must stay on the device. File size covers whether the file fits the limits of a browser-only workflow, where the standard cap is around 25 to 50 MiB depending on the tool. Label complexity covers whether your header or footer is a single short line or needs formatting such as dates, multiple lines, images, or different content per page.
Once those four answers are clear, the choice usually falls into one of three buckets: a browser-based tool that runs locally, a desktop publishing or office application that you install, or a custom script that you run against the file. Each bucket has a different strength profile, and the section below lines them up side by side.
Match the Method to Your Document
The table below maps the three main approaches to the most common job requirements. Use it to decide which path matches the document in front of you before you start typing text or installing software.
| Requirement | Browser-based local tool | Desktop publishing app | Custom script |
|---|---|---|---|
| File stays on device | Yes | Yes | Yes |
| File size limit | Bounded, typically 25 to 50 MiB | Limited by local disk | Limited by local disk and runtime memory |
| Custom font embedding | No | Yes | Yes, when the font file is available |
| Multilingual and non-Latin scripts | Limited to fonts the tool embeds | Yes | Yes |
| Centered single-line header or footer | Yes | Yes | Yes |
| Page-number tokens | Yes, where supported | Yes | Yes, written manually |
| Multi-line or rich layout | No | Yes | Yes |
| Different content per page or section | No | Yes | Yes |
| Speed for a one-off job | Fastest | Moderate | Slowest to set up |
| Setup cost | None | Install or license | Write or borrow code |
When the document is a typical report, contract, or manual that needs a single centered header or footer with optional "Page X of Y" numbering, the browser-based column covers the practical matches. When the document uses non-Latin characters, requires a brand font, or will be archived as a formal record, the desktop column is the safer choice.
Custom scripts sit in the last column on purpose, and they are useful for repeat work: the same label applied to hundreds of files, a batch of PDFs that need unique filenames per file, or a workflow that pulls metadata from another system. For a single one-off document, the cost of writing or borrowing code rarely pays back.
Limits and Boundaries to Plan Around
Every approach has boundaries, and choosing the right one means knowing which constraints apply to your file before you start. The table below lists the accepted values that change whether the tool can complete the task at all, regardless of which method you pick.
| Setting | Accepted values | Behavior at the edge |
|---|---|---|
| Font size | Whole numbers, 6 to 36 points | Reduced one point at a time down to 6 points when a line is too wide |
| Edge margin | Whole numbers, 0 to 200 points | Header sits below the top edge; footer sits above the bottom edge |
| Header text length | Up to 120 Unicode characters, trimmed | Empty entries skip that line |
| Footer text length | Up to 120 Unicode characters, trimmed | Empty entries skip that line |
| {page} token | Lowercase only | Replaced with the one-based current page number |
| {pages} token | Lowercase only | Replaced with the total structural page count |
| Input file size | Non-empty PDF up to 25 MiB | Encrypted, damaged, or oversized files fail visibly |
Beyond those input and output bounds, a few behaviors deserve attention. The tool draws inside the existing page box rather than expanding it, so existing body content near the chosen edge can overlap the new line, and that overlap is the reader's to manage. A line that does not fit horizontally is shrunk down to a 6-point floor rather than wrapped, stretched, or silently deleted, so very narrow pages or aggressive margins can leave little usable space. Page numbering in a uniform tool always begins at one and reflects the source page count before any text is added; there is no cover-page exclusion, no Roman-numeral mode, no starting-number offset, and no separate left and right alignment.
Once those limits are clear, the question becomes practical rather than conceptual: does your file fit, does your text fit, and will the result stay clear of body content? The next section answers those three questions for the browser path in concrete steps.
Add a Header and Footer with Header Footer PDF
For a single PDF that needs a centered header or footer plus simple numbering, Header Footer PDF handles the job without uploading the file or installing software. The steps below cover the entire flow from a blank browser tab to a downloaded PDF.
- Choose the local PDF. Use the file input to pick a PDF from your device. The file must be a non-empty PDF no larger than 25 MiB, and it cannot be password-protected or damaged.
- Enter the header text, the footer text, or both. Each field is optional, trimmed, and limited to 120 Unicode characters. To add numbering, include {page} for the current page number and {pages} for the total count; a footer such as "Page {page} of {pages}" becomes "Page 2 of 5" on the second page of a five-page document. Replacement is deterministic and applies everywhere the exact lowercase token appears; other brace text is left alone.
- 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 and positions header text below the top edge while placing footer text above the bottom edge. If a line is wider than the usable page width, the size shrinks to a 6-point floor rather than wrapping or stretching the text.
- Create the file and download it. Click "Add header and footer." The browser opens the source, draws the expanded text on every page, and produces a new PDF whose filename keeps the source base and adds -header-footer.pdf. Changing any setting revokes the previous download so it cannot be mistaken for the current configuration.
The implementation, drawing with embedded standard Helvetica and centering each line from its measured text width, is documented in the pdf-lib drawText reference.
After You Save: Verify the Output Before You Share
The new file is a real PDF, not a viewer-only overlay: the text is drawn as additional page content rather than a screen layer that disappears on print. That means it will look the same in a PDF reader, in a printed copy, and on a fax. Existing visible content, the source page order, and the original page count remain in place, but content already close to the edge can sit underneath the new line because the page box is not enlarged to make room.
A short verification routine prevents most surprises before a document is sent to a client or printed for a meeting. For a deeper walkthrough, see how to check the result after adding a header and footer to a PDF.
- Open the downloaded file and skim the first, middle, and last pages to confirm the label lands where you expected.
- Check the numbered pages to confirm that {page} starts at one and that {pages} reflects the original page count, not a page count that changed because of a duplicate source.
- Confirm that any non-Latin characters render correctly, or move the file to a desktop app if any character shows as a missing glyph.
- If the line was wide, zoom in to confirm the size shrank to the 6-point floor rather than overflowing the page box.
If any of those checks fail, change the font size or edge margin, or pick a different approach from the table above. The choice of tool does not change the underlying constraints, but it does change how much room you have to work around them.
If you're weighing options, Compare Approaches to Add a Header and Footer to a PDF covers this in detail.