How to Generate a Full-Height PDF in C#

A full-height PDF can mean either one unusually tall page that grows to fit its content, or a conventional document that flows across multiple fixed-size pages. For a single continuous page in a new C# layout, QuestPDF provides ContinuousSize(width): set the page width, and let the rendered content determine its height. For print-friendly reports, use a standard page size such as A4 or Letter and let the layout paginate.

The examples below focus on the first case: receipts, labels, compact reports, or other scroll-like output. They also cover HTML rendered with iText, measured iText 5 tables, output destinations, limits, and common layout failures. See the QuestPDF page settings documentation for the current API details.

1. Choose continuous height or normal pagination

First decide how the PDF will be read and used:

One tall page: useful when the document should behave like a receipt or scroll, remain one page, and be viewed digitally or printed on suitable roll media.
Multiple standard pages: better for ordinary reports, contracts, and documents that need predictable printing, page numbering, or page-by-page handling.
Content-derived dimensions: useful when both dimensions need to vary, subject to explicit bounds and reader support. QuestPDF also documents flexible page sizing.

A continuous page still needs a fixed width. Content height is a result of layout, so it cannot be reliably predicted from character count alone: fonts, wrapping, images, margins, and generated sections all affect the final height.

2. Create a continuous-height PDF with QuestPDF

Install QuestPDF in the project:

Continuous sizing keeps the page width fixed while the laid-out content determines its height.

dotnet add package QuestPDF

Here is a minimal runnable console application. It selects a 215-point page width, uses a 10-point margin, adds receipt content, and writes the resulting PDF to a file. QuestPDF requires a license configuration; choose the license type that matches your use and verify current eligibility and terms on its official license page before deployment.

using QuestPDF.Fluent;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;

QuestPDF.Settings.License = LicenseType.Community;

Document.Create(document =>
{
    document.Page(page =>
    {
        page.ContinuousSize(215); // Width in points; height follows content.
        page.Margin(10);

        page.Content().Column(column =>
        {
            column.Spacing(6);
            column.Item().Text("Example receipt").FontSize(18).Bold();
            column.Item().Text("Order: 10482");
            column.Item().Text("Date: 2026-09-29");
            column.Item().LineHorizontal(1);
            column.Item().Row(row =>
            {
                row.RelativeItem().Text("Item");
                row.ConstantItem(55).AlignRight().Text("Amount");
            });
            column.Item().Row(row =>
            {
                row.RelativeItem().Text("Notebook");
                row.ConstantItem(55).AlignRight().Text("$12.00");
            });
            column.Item().LineHorizontal(1);
            column.Item().Text("Total: $12.00").Bold();
        });
    });
}).GeneratePdf("full-height.pdf");

The page height adapts to the laid-out content while its width stays fixed. The number 215 is a width in points, not millimeters. The documentation also shows a width specified in millimeters; be deliberate about units when translating a physical receipt width into points. The actual rendered height depends on the final content and layout.

Make content data-driven

For a real receipt, create rows from a collection rather than hard-coding each item. Keep the column widths and text styles consistent so long names wrap predictably:

var items = new[]
{
    (Name: "Notebook", Amount: 12.00m),
    (Name: "Pen set with a longer description", Amount: 8.50m)
};

Document.Create(document =>
{
    document.Page(page =>
    {
        page.ContinuousSize(215);
        page.Margin(10);
        page.Content().Column(column =>
        {
            column.Item().Text("Order summary").FontSize(16).Bold();
            foreach (var item in items)
            {
                column.Item().Row(row =>
                {
                    row.RelativeItem().Text(item.Name);
                    row.ConstantItem(55).AlignRight()
                        .Text(item.Amount.ToString("C"));
                });
            }
        });
    });
}).GeneratePdf("order.pdf");

In production code, define currency and culture explicitly instead of relying on the machine’s default culture. For especially long output, consider whether one continuous page is appropriate for the consuming viewer and printer. If content can grow without a practical upper bound, standard pagination may be safer.

3. Select the right page-size behavior

Requirement	Approach	Considerations
One receipt-like page	`ContinuousSize(width)`	Width stays fixed; content determines height.
Print-ready report	Standard size such as A4, A3, Letter, or Legal	Layout flows across pages; headers, footers, and page numbers can be used.
Variable page dimensions	QuestPDF flexible page sizing	Set suitable minimum or maximum bounds when needed; pages can differ in size.
HTML source, one tall page	iText pdfHTML rendering and final media-box adjustment	Requires HTML rendering and careful viewer-limit handling.
iText 5 table content	Measure a width-locked table, then size the document	Specific to the older iText 5 API and table-driven layouts.

Continuous height solves a different problem from ordinary pagination. If a PDF is meant to be printed on common office paper, fixed-size pages are usually the practical choice. An extremely tall single page can be awkward to navigate, print, or process even if the PDF is valid.

A continuous page and conventional pagination solve different output needs.

4. Choose file, byte array, or stream output

QuestPDF supports three common output forms. The path form is convenient for a command-line tool or batch job:

document.GeneratePdf("report.pdf");

Return a byte array when another part of the application will upload or return the PDF:

byte[] pdfBytes = document.GeneratePdf();

Write to a stream for web responses or storage APIs that accept streams:

using var output = File.Create("report.pdf");
document.GeneratePdf(output);

For a web endpoint, avoid unnecessarily holding several large PDFs in memory at once. A continuous document may be very tall; its rendered output size depends on content, fonts, and images. Apply request limits and manage stream lifetimes in the hosting application.

5. HTML-to-PDF with iText pdfHTML

If the source is HTML, iText’s pdfHTML guide demonstrates rendering against an initially tall page, tracking the final content position, and then adjusting the page media box to the rendered extent. This is a distinct strategy from QuestPDF’s native continuous sizing. Follow the guide’s C# example and use its API matching your iText and pdfHTML versions: iText: how to create a PDF without page breaks.

The guide’s sample begins with a 595 by 14,400 user-unit page and adjusts the final page box after rendering. It includes a 36-unit adjustment in the sample’s calculation; treat that as part of that example’s spacing choice, not a universal constant to copy blindly. Measure the rendered content and tune margins for your HTML and fonts.

The same guide warns that Adobe Reader may fail to render pages exceeding 14,400 user units in either width or height. This is documented behavior for that reader, not a guarantee about every PDF viewer. Test the target readers and devices, and split the document into standard pages if the content may exceed a supported dimension.

6. Size an iText 5 page from a table

For a table-driven document using iText 5, the table must have a known width before its total height can be measured. Set TotalWidth, lock that width, and then inspect TotalHeight to inform the document’s custom page size. The underlying reason is that table height depends on its width: a narrow table wraps more and becomes taller. The iText knowledge-base example is version-scoped: iText 5: define page size based on content.

Do not treat an iText 5 table measurement pattern as a general API recipe for current iText versions or arbitrary HTML. For new code, select the library and version deliberately, and verify its API and licensing terms against official documentation.

7. Common errors and how to fix them

Symptom	Likely cause	Fix
Generated page is unexpectedly short or content is missing	Some content was not added to the page layout, or a constraint clipped it.	Check the page content tree and container constraints. Reproduce with a small document and add sections incrementally.
Text wraps differently than expected	Available width changed due to margins, fixed columns, font metrics, or long unbroken strings.	Confirm page width and margins, use sensible column widths, and handle long identifiers explicitly.
QuestPDF throws `DocumentLayoutException`	Layout constraints may be impossible, such as a child requiring more space than its parent allows.	Read the diagnostic, then relax conflicting size constraints or adjust the parent and child layout. QuestPDF notes that diagnostic text may contain snippets of document content; account for that before logging or forwarding exceptions.
iText HTML PDF is blank in Adobe Reader	The page dimension may exceed the guide’s documented 14,400-user-unit rendering threshold.	Keep dimensions within the documented limit, split content, or validate in the actual target reader.
iText 5 table reports zero height	The table width has not been set before reading height.	Set `TotalWidth` and `LockedWidth = true` before querying `TotalHeight`.
PDF looks correct on screen but prints poorly	A continuous page may be too long for the printer or print workflow.	Use standard pagination for office printing, or verify the target roll printer’s supported width and feed behavior.
Fonts or image dimensions vary across machines	The runtime environment may not have the same fonts or external assets.	Use controlled assets and fonts supported by the chosen library, and validate in the deployment environment.

8. Reliability, performance, and cost considerations

Bound input size: unbounded user content can create a very tall page, high memory use, or a PDF readers struggle to navigate. Set application-level limits and choose pagination when a maximum page dimension is needed.
Make rendering deterministic: use stable fonts, explicit culture and timezone choices for formatted data, and controlled image inputs. This reduces output differences between development and production environments.
Handle failures deliberately: catch layout and I/O errors at the job or request boundary, record a correlation identifier, and avoid putting sensitive document text in logs. For background generation, retry transient storage or network failures separately from deterministic layout failures.
Watch memory and concurrency: byte-array output keeps the entire result in memory. Streams can fit better into delivery pipelines, though rendering itself still requires resources. Limit concurrent rendering based on workload rather than allowing an unlimited queue.
Check licensing before shipping: the QuestPDF quick start describes eligibility criteria, including a revenue threshold, nonprofits, and FOSS projects. These are vendor terms that can change; confirm the current license and pricing pages for commercial use.
Compare operational costs: account for the PDF library license, application compute, storage, and any HTML conversion dependencies. This research does not establish current iText or QuestPDF pricing for your particular deployment.

9. Or skip the browser setup

If the PDF source is a live web page rather than content your C# app lays out, ScreenshotNeo can return a screenshot or PDF from one GET request. It is a website screenshot API and MCP server by Yorker Media. Its API can capture a page as PDF; check the API documentation for supported parameters and response behavior.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -d format=pdf \
  -o page.pdf

For a C# caller, use HttpClient and save the response bytes:

using System.Net.Http;

using var http = new HttpClient { Timeout = TimeSpan.FromSeconds(90) };
var query = "access_key=YOUR_API_KEY&url=https%3A%2F%2Fstripe.com&format=pdf";
using var response = await http.GetAsync(
    "https://api.screenshotneo.com/v1/shot?" + query);
response.EnsureSuccessStatusCode();
await using var output = File.Create("page.pdf");
await response.Content.CopyToAsync(output);

The product’s stated behavior and plan details are:

Cookie and consent banners, newsletter popups, and chat widgets from more than 60 known platforms are removed before capture; each step can be turned off.
Bot checks, CAPTCHAs, blank pages, timeouts, failed loads, and cache hits are not billed. Response headers say which page verdict occurred and whether it was billed.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients.
The free plan includes 1,000 shots per month with no card. Paid plans start at $5 for 3,000 shots; higher tiers are Growth $15 for 15,000, Pro $39 for 60,000, Scale $99 for 250,000, and Business $249 for 1,000,000. Yearly billing gives two months free, and every feature is on every plan.

This is useful for rendering an existing public page, while QuestPDF is the direct fit when your application needs to compose a custom document from data and layout components. Create a free ScreenshotNeo account for 1,000 screenshots a month, with no card required.

10. Frequently asked questions

Does “full-height” mean the PDF has no page breaks?

In this guide, it means a single continuous page whose height follows content. If you want content to continue over ordinary sheets, use standard page dimensions and pagination instead.

Can I know the exact height before rendering?

Only if you accurately account for the layout inputs, including fonts, wrapping, images, and margins. In most cases, generate the document and inspect its resulting page dimensions rather than estimating from text length.

Should every long report use one tall page?

No. Long continuous pages can be difficult to print, navigate, or open in some readers. Use standard pages when compatibility, print handling, or page-level navigation matters.

Can I use QuestPDF for a commercial application?

Check the current official license terms for your organization’s situation before shipping. The eligibility rules and pricing can change.

Implementation checklist

Choose one continuous page only when the output is naturally receipt- or scroll-like.
Set the width with explicit units and account for margins and column widths.
Test long text, empty data, large images, and the largest expected document.
Choose file, byte-array, or stream output based on the consuming application.
Validate the generated PDF in the target viewers and print workflow.
Confirm the current library API and license terms before deployment.

For a new C#-native document, begin with QuestPDF’s continuous page sizing. For conventional reports, let standard pages handle the flow. For HTML or table-driven legacy code, use the corresponding iText strategy with its documented limits and version scope in mind.