Memory Cap of 4GB when converting HTML to PDF

Hi - I’m currently testing a conversion of html to pdf with the code below and it looks like the memory usage runs up to about 4GB then gets re-allocated. Do you know if this can be minimized at all for machines that may not have that much memory?

Code:
Action convertHtmlToPdf = () =>
{
const string TestingHtml = @“.\test.html”;

       Converter.ConvertHTML(TestingHtml, new PdfSaveOptions(), $@".\{Guid.NewGuid()}.pdf");

       Console.WriteLine($"Converted 1 document");
   };

    List<Task> convertTasks = new List<Task>();

    for (int counter = 0; counter < 20; counter++)
    {
        convertTasks.Add(Task.Run(convertHtmlToPdf));
    }

    await Task.WhenAll(convertTasks);

@jtfinlayson

I cannot confirm version-specific behavior from the retrieved release notes/changelog/docs. Treat the following as a hypothesis.

You mentioned that memory usage climbs to around 4 GB when converting HTML to PDF in parallel tasks.

To investigate the memory behavior in Aspose.HTML for .NET, could you provide the following details?

  • The exact version of Aspose.HTML for .NET you are using (including any updates/patches).
  • Whether the application runs as a 64‑bit process and the target .NET runtime (e.g., .NET 6, .NET Framework 4.8).
  • An approximate description of the size and complexity of test.html (number of images, CSS files, scripts, etc.).

With this information we can better assess the memory usage and suggest ways to reduce it. Please share the details here, and we’ll continue the investigation in this thread.

Yes I’m using Aspose.HTML version 26.1 running in .NET 9 and 64.bit. The test.html file is 7MB with only about 2 images but alot of plain text.

@jtfinlayson

You’re seeing the process memory rise to around 4 GB when many Converter.ConvertHTML calls run in parallel with Aspose.HTML 26.1 on a 64‑bit .NET 9 process.

What’s happening
The parallel execution triggers a memory‑leak issue that was reported earlier and tracked as HTMLNET‑6193. The issue was addressed in a later library update [2].

How to keep memory usage low

  1. Upgrade the library – Move to the newest Aspose.HTML for .NET version that includes the fix for HTMLNET‑6193. This resolves the uncontrolled memory growth observed with parallel conversions.
  2. Throttle parallel conversions – Limit the number of concurrent ConvertHTML calls, for example with a SemaphoreSlim:
    var semaphore = new SemaphoreSlim(4); // up to 4 concurrent conversions
    async Task ConvertAsync(string htmlPath)
    {
        await semaphore.WaitAsync();
        try
        {
            Converter.ConvertHTML(htmlPath, new PdfSaveOptions(),
                                  $@".{Guid.NewGuid()}.pdf");
        }
        finally { semaphore.Release(); }
    }
    
    Reducing concurrency prevents the memory‑leak from being exercised simultaneously.
  3. Optional GC call – After a batch of conversions you can invoke GC.Collect(); GC.WaitForPendingFinalizers(); to help the runtime reclaim any residual memory, though this is not a guaranteed fix.

Key points

  • The memory spike is associated with parallel use of Converter.ConvertHTML; upgrading or limiting concurrency mitigates it.
  • The size of your test.html (7 MB, mostly text, two images) is not unusually large, so the pressure comes from the conversion engine rather than the input file.
  • The observed 4 GB usage is a symptom of the issue, not a documented hard limit of the product.

If you upgrade and still see high memory consumption, please share a minimal reproducible sample (e.g., a small HTML file and the exact conversion code) so we can continue the investigation in this thread.

Here is the conversion code we are using, I’ve leveraged doing it in parallel but I’m still seeing 4GB be used:

// Example usage: processing 10 items with a limit of 2 concurrent tasks
var itemsToProcess = Enumerable.Range(1, 10);

    Parallel.ForEach(itemsToProcess, new ParallelOptions { MaxDegreeOfParallelism = 2 }, item =>
    {
        Converter.ConvertHTML(testHtml, new PdfSaveOptions(), $@".\{Guid.NewGuid()}.pdf");
    });

Here is the HTML file we are using:

test.7z (55.7 KB)

@jtfinlayson

We have opened the following new ticket(s) in our internal issue tracking system and will deliver their fixes according to the terms mentioned in Free Support Policies.

Issue ID(s): HTMLNET-6950

You can obtain Paid Support Services if you need support on a priority basis, along with the direct access to our Paid Support management team.