For formal documents like contracts, reports, and weekly summaries, headers and footers are non-negotiable: the header carries the document title or company name, the footer carries the page number, and everything reads, prints, and archives more professionally. Yet in many frontend PDF solutions, headers and footers are either unsupported or must be added page by page — a miserable workflow. dompdf.js supports headers, footers, and page numbers natively. Combined with the @page paged media properties, standard CSS syntax generates running headers, footers, and page numbers automatically, supports the "Page X of Y" format, and can even suppress numbering on cover pages. This guide walks through the common configurations, design guidelines, and special-page handling with complete code examples. The examples are deliberately minimal so the syntax is easy to lift into real templates: every configuration shown here works in production documents, from one-page memos to hundred-page contracts. Headers and footers are also a branding surface: the same rules that carry a company name and page numbers turn a plain export into a document that looks like it came from a publishing system. Once the pattern is in place, maintaining it costs almost nothing — one style block controls every page of every document generated by the same template.
Nearly every formal document needs them: bid documents put the project name and company in the header, contracts put page numbers in the footer, weekly reports put the department name in the header. Uniform, complete information makes a document look trustworthy. Headers and footers also carry operational information: confidentiality markings, version numbers, and approval statuses live naturally in the margin areas, visible on every page without cluttering the body.
PDFs without headers and footers are hard to navigate once printed or bound — chapters and page numbers blur together, especially in multi-page documents. Adding them manually on every page is slow and error-prone, and any layout change means redoing everything. For documents that are scanned and archived, a header with the document ID and a footer with page numbers make each scanned page self-identifying even after separation.
dompdf.js generates headers and footers at layout time and refreshes them as pagination proceeds: configure once, it applies everywhere, and template changes propagate to every page automatically. Maintenance cost is essentially zero. The convention is so universal that its absence reads as an error: readers expect to find their place by page number, and a document without one forces clumsy counting.
Legal and procurement teams are often the loudest advocates for headers and footers: contracts without page numbers are a liability in negotiation, and 'page X of Y' is frequently a contractual requirement.
Consistency across a document family matters too: when every report from the same system carries the same header layout, the organization's documents become recognizable at a glance.
Because dompdf.js renders headers at layout time, the same template can produce a memo today and a quarterly report next month — the header simply reflects whatever title and date the data provides.
In regulated documents, headers and footers often carry more than branding: reference numbers, approval dates, and distribution lists appear in the margin areas so the body text stays clean while the document remains fully traceable.
Headers typically hold the document title, company name, or logo, set smaller and lighter than body text so they do not compete with the content; footers usually carry the page number, date, or confidentiality level, keeping information minimal. A common proportion is roughly 9–10pt header text against an 11–12pt body, with a subtle color or a thin rule under the header to separate it from content.
Headers and footers must stay out of the body area: reserve space for them through @page margins, and body content flows inside the content box, so nothing overlaps — even in print and binding. Designers should also consider the gutter: documents that will be bound need extra inside margin so the header and footer are not swallowed by the binding.
Common layouts: title centered in the header and page number centered in the footer, or title on the left with page number on the right. Positioning is controlled with standard CSS paged media syntax — flexible and intuitive. Restraint pays off: one piece of information per margin zone keeps headers and footers scannable, while crowding them with too many fields defeats their purpose.
The footer is a good place for the smallest, least important details — page number, date, confidentiality level — because readers glance at it, while the header carries the document's identity.
Mirrored layouts, where the page number alternates between the left and right corners, suit double-sided printing and are expressed with standard paged-media selectors.
Whitespace around header and footer content matters as much as the text itself; generous margins make a formal document feel composed rather than crowded.
Typography in the margins should echo the body's typeface family for cohesion, but at a smaller size and lower contrast; the header and footer are furniture, not content, and should never compete with the text.
@top-center defines the header content and @bottom-center the footer content. counter(page) is the current page number and counter(pages) the total, combined into the standard "Page X of Y" format. The margin values in the example are deliberate: the top and bottom margins are larger than the sides because they must also house the header and footer bands.
Headers and footers repeat automatically on every page and page numbers increment as pagination proceeds — no per-page code at all, and every page of a multi-page document carries complete information. Because the header and footer are declared inside the page rule, they automatically apply to every page the pagination engine creates, including pages that did not exist when the template was written.
Margins must reserve room for headers and footers: the top margin includes header height and the bottom margin includes footer height, so body content lays out inside the content box and never overlaps them. The content property accepts plain text and counters together, so mixing a static label with the dynamic page number is a single line.
If the header should differ on the first page — for example, a title page without a running header — named pages or the exclusion mechanism handle it without duplicating the template.
The same style block can carry several margin boxes: a logo at top-left, the title at top-center, and the page number at bottom-right give a professional three-zone layout from one declaration.
For debugging, start with plain text in the margin boxes and add images and counters once the basic layout is confirmed; the syntax is forgiving, and the rendered PDF shows the result instantly.
When several documents share a corporate header, extract the page rule into a shared CSS string and reuse it across templates; a rebrand then touches one file instead of every document generator.
import { DomPDF } from 'dompdf.js';
const html = `
<style>
@page {
size: A4;
margin: 25mm 20mm 30mm 20mm;
@top-center { content: "Weekly Project Report · Week 33, 2026"; }
@bottom-center { content: "Page " counter(page) " of " counter(pages); }
}
</style>
<h1>Weekly Project Report</h1>
<p>Progress: core modules finished integration testing, entering regression testing.</p>
<p>Risk: third-party API delay, vendor confirmed recovery next week.</p>`;
const pdf = new DomPDF();
pdf.addPage(html, { format: 'A4', margin: '20mm' });
pdf.save('weekly-report.pdf');Page number formats are freely composable: plain digits, prefixed forms like "Page 1", slash-separated forms like "1/8", or mirrored left-right layouts. Whatever the content property says is exactly what appears in the PDF. Because the content property is a template, any combination of static text, counters, and dynamic values is possible — 'Confidential · Page 3 of 12' is one line away.
Headers can hold images too — a company logo as a data URL or hosted URL — mixed with text, which suits branded formal documents. Embedded images keep their sharpness in vector output. Images in headers stay sharp because the whole document is vector; a logo embedded once renders crisply on every page.
Use one consistent set of header and footer rules across a multi-page document, combined with pagination control, so style stays uniform from the first page to the last and archiving looks professional. Formatting choices should follow the audience: internal reports tolerate compact forms like 3/12, while client documents usually read better as 'Page 3 of 12'.
Counter arithmetic extends the formats further: the page counter can be offset for documents that continue numbering from a previous part, keeping a multi-volume series consistent.
If documents must show the generation date, the template can inject it at build time, so the footer reads 'Generated 2026-08-18' — useful for versioned deliverables.
Consistency across the document family beats cleverness: pick one header and footer scheme for a template and apply it everywhere, so the archive looks uniform rather than experimental.
For multilingual documents, the header and footer text can be generated per language by interpolating translated labels into the content properties, so one template serves the whole organization's language set.
Formal reports usually open with a cover page, and covers typically show no header, footer, or page number. dompdf.js provides an exclusion mechanism so specified pages can skip headers and footers, honoring standard document conventions. The exclusion mechanism is declarative: the template states which pages skip headers and footers, so the rule survives content edits that shift page counts.
Lay out the cover as its own page: addPage the cover first, then addPage the body, and let body page numbering start from 1 — matching how readers actually navigate the document. Planning the page sequence before building the template — cover, table of contents, body, appendix — makes the exclusions obvious and the implementation a few lines.
Table-of-contents pages and appendices can be handled on demand as well. Plan the document structure first, then decide which pages show headers and footers — the control is precise and the structure stays clear. Readers orient themselves by the visible numbering: when the cover is unnumbered and the body starts at 1, printed page numbers match the document's internal references.
A cover page without numbering also protects the first impression: the title page stays clean, and the formal numbering starts exactly where the content does.
Appendices can restart or continue numbering depending on convention; the same tools that exclude covers can drive appendix numbering policies.
When the document is assembled from multiple addPage calls, the exclusion and numbering rules apply across the whole assembly, so a cover from one source and a body from another still produce a coherent file.
A table of contents can share the cover's exclusion treatment if the convention requires it; the decision is a template rule, and changing it later is a one-line edit rather than a re-layout.
Q: Does Chinese render correctly inside headers and footers? A: Yes. The built-in Source Han Sans SC font renders header and footer text as clearly as body text — company names and document titles never garble. If the document mixes languages, embed the matching fonts so header text in any script renders with the same fidelity as the body.
Q: Can numbering start somewhere other than page 1? A: Yes. Combine pagination with the exclusion mechanism so the body starts counting from a chosen page, leaving covers and tables of contents uncounted, as formal documents require. The same declarative rules that exclude covers can also offset the starting number, so any page can become page 1.
Q: Can the header contain dynamic data? A: Yes. Template string concatenation fills dynamic content — document titles, dates, project names — at generation time, so one template adapts to many documents. A header is just a margin box like any other, so anything a body page can show — text, images, counters — can appear in a header too.
Q: Can headers and footers contain images, such as a logo? A: Yes — data URLs and hosted URLs both work, and the vector pipeline keeps logos sharp on every page, in print and on screen.
Q: Do headers and footers slow down generation? A: Negligibly — they are part of the same layout pass as the body; a multi-page document with full headers, footers, and page numbers still exports in about the same time as one without them.
Q: Can page numbering continue across separately generated documents? A: Yes — set the starting counter when assembling a series, so part one ends at 12 and part two begins at 13, keeping a multi-volume set continuous.
Q: Is it possible to show different footers on even and odd pages? A: Yes — paged-media selectors distinguish left and right pages, which is exactly how book-style alternating footers are implemented.
下面的按钮用 dompdf.js 在浏览器端实时生成 PDF，无需后端：