Class BrowserPoolOptions

Configuration options for the browser tab pool, which reuses browser tabs across renders to eliminate subprocess startup latency.

These settings are process-level — a single pool is shared across all instances. Changing these values affects all subsequent renders in the application.

Inheritance
System.Object
BrowserPoolOptions
Namespace: IronPdf
Assembly: IronPdf.dll
Syntax
public class BrowserPoolOptions : Object

Working with PDF generation in IronPDF runs through BrowserPoolOptions. It represents configuration options for the browser tab pool, which reuses browser tabs across renders to eliminate subprocess startup latency.

BrowserPoolOptions matters when an application needs to configure or invoke PDF generation from C# code. The class encapsulates the related options and behavior in a single object that is set up once and reused across render or processing calls. Typical scenarios include batch generation pipelines, templated document workflows, and integration with existing C# document services.

To use BrowserPoolOptions, instantiate or obtain it from the relevant entry point in the IronPDF C# API. Key properties include Enabled, IdleTimeoutSeconds, MaxIdleTabs. Assign options or invoke methods on the instance to configure or perform the operation.

using IronPdf;

var instance = new BrowserPoolOptions();
var current = instance.Enabled;
// Read or assign other properties such as IdleTimeoutSeconds, MaxIdleTabs
instance.ToString();

For the broader workflow, see the IronPDF C# documentation for related how-to guides and examples. For broader context, the PDF generation portion of the IronPDF C# API contains related types that work with BrowserPoolOptions directly. BrowserPoolOptions exposes additional members beyond those highlighted above; the reference tables on this page list the full set. In application code, treat BrowserPoolOptions as a configured object that is constructed once and reused across operations rather than instantiated per call. Configuration is generally idempotent: assigning the same property value twice has the same effect as assigning it once. For diagnostic purposes, inspect the relevant BrowserPoolOptions property after each operation to confirm the configured state. See the constructors, properties, and methods tables below for the complete API surface of BrowserPoolOptions. Application code typically obtains or instantiates a single BrowserPoolOptions and shares it across multiple IronPDF operations rather than recreating it per call.

Constructors

BrowserPoolOptions()

Declaration
public BrowserPoolOptions()

Properties

Enabled

Enables or disables the browser tab pool.

When enabled, browser tabs are returned to a pool after rendering instead of being destroyed. The next render reuses a "warm" tab with its renderer subprocesses already running, avoiding the subprocess startup cost.

When set to false, every render creates a new browser tab, spawns new subprocesses, and destroys everything on completion. There is zero difference in behavior, memory usage, or output.

Default value is true.

Declaration
public bool Enabled { get; set; }
Property Value
Type Description
System.Boolean

IdleTimeoutSeconds

Number of seconds an idle browser tab remains in the pool before being destroyed.

After a render completes and the tab is returned to the pool, a background thread periodically checks for tabs that have exceeded this timeout and destroys them to reclaim memory.

Default value is 30. Minimum value is 5.

Declaration
public int IdleTimeoutSeconds { get; set; }
Property Value
Type Description
System.Int32
Remarks

Trade-off: Longer timeouts increase the chance of a warm tab being available for the next render, but hold memory longer during quiet periods.

Recommended values:

• 10 — Fast memory reclaim. Suitable for sporadic, bursty traffic.

• 30 (default) — Covers most typical web application request intervals.

• 60 — Suitable for batch processing pipelines or high-traffic APIs.

The actual destruction may occur up to 5 seconds after the timeout, depending on the internal cleanup interval.

Only relevant when Enabled is true and MaxIdleTabs is greater than 0.

MaxIdleTabs

Maximum number of idle browser tabs kept alive in the pool.

Each idle tab retains its renderer subprocesses in memory, consuming approximately 50–100 MB of RAM. When a new render arrives, a warm tab is used instead of creating a new one, eliminating subprocess startup latency.

Default value scales with your hardware: Environment.ProcessorCount / 2, clamped between 1 and 4. For example, a 4-core machine defaults to 2 idle tabs, while an 8+ core machine defaults to 4.

Minimum value is 0.

Declaration
public int MaxIdleTabs { get; set; }
Property Value
Type Description
System.Int32
Remarks

Recommended values:

• 0 — No tabs kept idle. Equivalent to disabling the pool.

• 1 — Minimal overhead (~50–100 MB). Suitable for sequential workloads, single-core containers, or low-memory environments such as Azure Basic tier.

• 2 — Handles typical body + header/footer render patterns. ~100–200 MB overhead. Good default for 4-core machines and Azure Standard tier.

• 4 — Maximum default. Good for high-concurrency servers with 8+ cores. ~200–400 MB overhead.

Going beyond 4: You can set values higher than 4 if your workload involves many concurrent renders on a high-core-count server (e.g., 16+ vCPUs) with ample memory.

However, returns diminish beyond 4 because the CEF browser process serializes events through a single thread, limiting how many renders truly run in parallel. Most workloads see no benefit above CPU cores / 2.

Memory note: Idle tabs hold the previous document's DOM in renderer memory until the tab is reused or destroyed after IdleTimeoutSeconds. On memory-constrained environments, prefer a lower value paired with a shorter timeout.

Only relevant when Enabled is true.

Methods

ToString()

Returns a summary of the current pool configuration for diagnostic purposes.

Declaration
public override string ToString()
Returns
Type Description
System.String