Always Use 64-Bit Architecture with IronOCR

Updated:June 28, 2026

IronOCR runs memory-intensive work under the hood, so a 32-bit (x86) build hits the ~2GB memory ceiling and starts failing on large or high-volume documents. Targeting 64-bit (x64) is the fix.

A 32-bit process is capped at roughly 2GB of usable memory no matter how much RAM the machine has. Under that limit, OCR work commonly surfaces as:

System.OutOfMemoryException

Other symptoms of the same ceiling include deadlocks during OCR engine execution, resource starvation in image preprocessing, crashes or unhandled exceptions, and OCR results that time out or fail silently.

The pressure comes from the operations IronOCR performs per document: high-resolution image rendering, temporary rasterization, optical character recognition, and deep text extraction using a machine learning model (used by the AdvancedScan methods and SearchablePDF output). Each of these can demand hundreds of MB per document, and multi-page PDFs, multi-page TIFFs, and 300+ DPI images push that higher.

Please noteIronOCR also calls native libraries for OCR, image rendering, and PDF rasterization. These allocate unmanaged memory the .NET garbage collector cannot see, which adds even more pressure in a 32-bit process.

Solution

Option 1: Set the platform target in Visual Studio

Switch the project to x64 through the build settings:

Right-click your project and open Properties.
Open the Build tab.
Set Platform target to x64.
Leave Prefer 32-bit unchecked.

Option 2: Set the target from the CLI or .csproj

Publish against a 64-bit runtime to enforce the architecture at build time:

dotnet publish -c Release -r win-x64

dotnet publish -c Release -r win-x64

SHELL

Or pin the target directly in your .csproj:

<PropertyGroup>
  <PlatformTarget>x64</PlatformTarget>
  <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>

<PropertyGroup>
  <PlatformTarget>x64</PlatformTarget>
  <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>

XML

The <Prefer32Bit>false</Prefer32Bit> line matters when the project is AnyCPU: with it enabled, the app still launches as a 32-bit process and inherits the same ceiling.

WarningAvoid "AnyCPU" with "Prefer 32-bit" enabled. It quietly reintroduces the 2GB limit even on a 64-bit machine.

When to Suspect Architecture

Check the architecture first if you see OCR jobs stalling or crashing unexpectedly, intermittent out-of-memory exceptions, or performance degradation on high-volume documents. If you are running on x86, switch to x64 before investigating anything else.

Keep a few habits in production:

Target x64 for production: it is the only supported configuration for heavy OCR workloads.
Develop on x64: testing on x64 mirrors real-world memory behavior and surfaces issues early.
Build 64-bit Docker images: make sure the base image is linux/amd64.

Note that concurrent OCR work spikes memory fast. Even with small documents, multi-threaded or async operations can climb quickly.

If You Cannot Change Architecture

When x64 is not an option, break large documents into smaller chunks and process at a lower resolution. Expect a trade-off in performance and accuracy. Stable support for 32-bit projects is currently under investigation.

Curtis Chau

Chat with engineering team now

Technical Writer

Curtis Chau holds a Bachelor’s degree in Computer Science (Carleton University) and specializes in front-end development with expertise in Node.js, TypeScript, JavaScript, and React. Passionate about crafting intuitive and aesthetically pleasing user interfaces, Curtis enjoys working with modern frameworks and creating well-structured, visually appealing manuals.

...

Ready to Get Started?

Nuget Downloads 6,106,091 | Version: 2026.7 just released