HTML Print Pagination & Footer: 6 Approaches Compared

Table of Contents

• Approach 1: CSS @page with counter()
• Approach 2: Fixed Position Footer (Manual)
• Approach 3: JavaScript-Generated Page Numbers
• Approach 4: Running Headers/Footers with Named Pages
• Approach 5: Table-Based Pagination
• Approach 6: CustomJS Automatic Pagination
• Comparison & Recommendations

Approach 1: CSS @page with counter()

The most elegant and standards-compliant approach is using CSS Paged Media with @page rules and the counter(page) function. This CSS feature was specifically designed for print layouts and allows you to place content in page margin boxes like @bottom-center, @bottom-right, etc.

How It Works

CSS defines special page margin boxes where you can place running content that appears on every page. You can access the current page number with counter(page) and the total page count with counter(pages).

Pros

• Standards-compliant: Part of the CSS Paged Media specification
• Clean separation: Footer logic stays in CSS, not cluttering HTML
• Automatic: No JavaScript needed, works purely with CSS
• Flexible positioning: Multiple margin boxes available (top-left, bottom-center, etc.)

Cons

• Limited browser support: Chrome/Chromium don't support counter(pages) for total page count
• Requires specialized PDF engines: Works well with PrinceXML, WeasyPrint, but not Chrome headless
• Limited styling: Page margin boxes have restricted styling capabilities

Browser/Engine Support

• ✅ PrinceXML: Full support
• ✅ WeasyPrint: Good support
• ⚠️ Chrome Headless: Partial support (counter(page) works, counter(pages) doesn't)
• ❌ Standard browsers: Very limited support

Best Use Cases

Ideal when you're using PDF engines like PrinceXML or WeasyPrint and need a clean, CSS-only solution. Not recommended for Chrome-based solutions unless you only need current page numbers (not total pages).

Approach 2: Fixed Position Footer (Manual)

A simple but effective approach is to use CSS position: fixed with bottom: 0 to create a footer that appears on every printed page. This works across all browsers and PDF engines, making it the most compatible solution.

How It Works

By setting a footer element to position: fixed within a @media print block, the footer automatically repeats on every page during PDF generation. You add manual page numbers or use JavaScript to inject them.

Pros

• Universal support: Works in all browsers and PDF engines
• Simple implementation: Just CSS, no complex logic needed
• Full styling control: You can style the footer however you want
• Works with Chrome Headless: Perfect for CustomJS and Puppeteer

Cons

• No automatic page numbers: You need to add them manually or via JavaScript
• Content overlap: You must manually add bottom padding/margin to prevent content from hiding under the footer
• Static content only: Can't show dynamic "Page X of Y" without JavaScript

Browser/Engine Support

• ✅ All PDF engines: Universal support
• ✅ Chrome Headless/CustomJS: Works perfectly
• ✅ Standard browsers: Full support

Best Use Cases

Perfect for simple footers with static content (company name, document title, date). Also great when combined with JavaScript for dynamic page numbers. This is the most reliable approach for Chrome-based PDF generation.

Approach 3: JavaScript-Generated Page Numbers

This approach combines fixed-position footers with JavaScript to dynamically inject page numbers. Before generating the PDF, JavaScript calculates the total number of pages and inserts "Page X of Y" text into footer elements.

How It Works

The HTML includes placeholder footer elements on each page. JavaScript runs before PDF generation to: 1) Calculate total pages by measuring document height vs page height 2) Insert dynamic page numbers into each footer placeholder 3) Then the PDF is generated with all page numbers in place

Pros

• Full page number support: Shows "Page X of Y" with accurate total count
• Works everywhere: Compatible with all browsers and PDF engines
• Highly customizable: You can format page numbers however you want
• Dynamic content: Can add timestamps, user names, or any calculated data

Cons

• Requires JavaScript: More complex than pure CSS solutions
• Timing issues: Must run after page layout is complete but before PDF generation
• Page calculation complexity: Estimating page count can be tricky with variable content
• Manual maintenance: Need to ensure JavaScript runs at the right time

Browser/Engine Support

• ✅ Chrome Headless/CustomJS: Perfect fit, full control over timing
• ✅ Puppeteer: Excellent support with page.evaluate()
• ✅ All PDF engines: Works universally once JavaScript has run

Best Use Cases

Ideal for Chrome-based PDF generation where you need accurate "Page X of Y" footers. Perfect when using CustomJS or Puppeteer, as you can execute the JavaScript before PDF generation.

Approach 4: Running Headers/Footers with Named Pages

An advanced CSS Paged Media technique using named pages and running elements. This allows you to define different headers/footers for different sections of your document (e.g., different footer for title page vs content pages).

How It Works

You define named page types using @page chapter, @page cover, etc. Then assign elements to specific pages with page: chapter; in CSS. Each named page can have its own header/footer configuration.

Pros

• Section-specific footers: Different footers for different document sections
• Professional layouts: Creates book-quality pagination
• Running elements: Can extract content from document to use in headers
• Standards-based: Part of CSS Paged Media Level 3 specification

Cons

• Very limited browser support: Only works with specialized PDF engines
• Not supported in Chrome: Won't work with Chrome Headless or CustomJS
• Complex syntax: Steeper learning curve than other approaches
• Engine-specific quirks: Behavior varies between PrinceXML and WeasyPrint

Browser/Engine Support

• ✅ PrinceXML: Excellent support with extensions
• ⚠️ WeasyPrint: Partial support, some features missing
• ❌ Chrome Headless/CustomJS: Not supported
• ❌ Standard browsers: No support

Best Use Cases

Best for complex documents like books, manuals, or reports with multiple sections that need different pagination styles. Only viable when using PrinceXML or similar professional PDF engines.

Approach 5: Table-Based Pagination

This creative approach uses HTML tables with thead and tfoot elements that automatically repeat on every page. By placing footer content in <tfoot>, browsers will repeat it at the bottom of each printed page.

How It Works

You wrap your entire document content in a table. The <tfoot> element contains your footer, and browsers automatically repeat <thead> and <tfoot> on every page when a table spans multiple pages during printing.

Pros

• Automatic repetition: Browsers handle footer repetition natively
• No JavaScript needed: Pure HTML/CSS solution
• Wide browser support: Works in Chrome, Firefox, and most PDF engines
• Bonus headers: Can also add repeating headers with <thead>

Cons

• Semantic misuse: Using tables for layout is not semantically correct
• Styling limitations: Table styling can be restrictive
• No dynamic page numbers: Can't show "Page X of Y" without JavaScript
• Layout constraints: Everything must fit within table structure

Browser/Engine Support

• ✅ Chrome Headless/CustomJS: Works well
• ✅ Firefox: Good support
• ⚠️ Safari: Works but with some quirks
• ✅ Most PDF engines: Generally supported

Best Use Cases

Useful for tabular reports or invoices where table structure makes sense. Good fallback option when you need repeating footers without JavaScript but can't use position:fixed or @page rules.

Approach 6: CustomJS Automatic Pagination

CustomJS offers built-in pagination features that automatically handle page numbers and footers for you. This is the most developer-friendly approach, combining the best aspects of all previous methods while handling the complexity behind the scenes.

How It Works

CustomJS provides special configuration options when generating PDFs. You can specify footer templates with variables like and , and CustomJS automatically injects the correct values on every page.

Pros

• Zero configuration: Works out of the box with simple templates
• Accurate page numbers: Always shows correct "Page X of Y"
• Professional quality: Consistent, reliable output every time
• Flexible templates: Support for custom HTML/CSS in headers and footers
• No timing issues: CustomJS handles all the complexity of when to inject page numbers

Cons

• Requires CustomJS: Only works with CustomJS service, not a general solution
• Service dependency: Need an API key and internet connection

Browser/Engine Support

• ✅ CustomJS: Perfect support (it's built for this!)
• ❌ Other engines: CustomJS-specific feature

Best Use Cases

Perfect for production applications where you need reliable, professional pagination without dealing with browser quirks or JavaScript complexity. Ideal when you're already using CustomJS for HTML-to-PDF conversion.

Comparison & Recommendations

Here's a comprehensive comparison of all six approaches to help you choose the right one for your use case:

📋 Decision Guide

🏆 Our Recommendation

For most modern web applications generating PDFs from HTML, we recommend CustomJS (Approach 6). It provides the best developer experience, most reliable output, and eliminates all the browser compatibility headaches. The built-in pagination features are production-ready and handle edge cases that would take weeks to solve manually.

If you need a free, self-hosted solution, use Approach 3 (JavaScript) with Chrome Headless or Puppeteer. It requires more code but gives you full control and works reliably.

Avoid Approach 4 (Named Pages) unless you're already invested in PrinceXML, as the limited browser support makes it impractical for most use cases.