[Public] Why You Should Always Use 64-Bit Architecture with IronOCR

Overview

When working with IronOCR, performance and stability are key — especially in production environments handling high volumes of document processing. One critical configuration that often gets overlooked is project architecture — specifically whether your application targets 32-bit (x86) or 64-bit (x64).

Always target 64-bit architecture (x64) when using IronOCR to avoid memory-related issues during intensive OCR and image processing tasks.

 

---

Why This Matters

IronOCR performs memory-intensive operations under the hood, including:

• High-resolution image rendering

• Temporary rasterization

• Deep text extraction using Machine Learning model (if you AdvancedScan methods are used or output SearchablePDF)

• Optical character recognition

These processes can demand hundreds of MBs or more per document, especially when working with:

• Multi-page PDF documents

• Multi-page TIFFs

• High-resolution images (300+ DPI)

If your application targets 32-bit, it will be limited to ~2GB of usable memory, regardless of how much RAM your machine has. This can lead to:

 

Common Issues with 32-bit Architecture:

• System.OutOfMemoryException

• Deadlocks during OCR engine execution

• Resource starvation in image preprocessing

• Application crashes or unhandled exceptions

• OCR results timing out or failing silently

---

Solution: Target 64-bit (x64) Architecture

 

How to Check and Set Architecture

 

General Solution using Visual Studio UI:

1. Right-click your project > Properties

2. Go to the Build tab

3. Set Platform target to x64

4. Optional: Set Prefer 32-bit to unchecked

 

Alternative using CLI:

Ensure you're running the app with a 64-bit .NET runtime. You can enforce this by publishing for a specific runtime:

 

Or update your .csproj:

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

 

---

When to Check for Architecture Issues

If you encounter:

• OCR jobs stalling or crashing unexpectedly

• Intermittent out-of-memory exceptions

• Performance degradation on high-volume documents

Check if you're running on x86 and switch to x64 before investigating further.

 

---

Best Practices

• Always target x64 for production environments

• Test on x64 during development to mimic real-world scenarios

• Avoid using "AnyCPU" with "Prefer 32-bit" enabled

• If using Docker, ensure your base image is 64-bit (linux/amd64)

---

Additional Notes

• IronOCR internally utilizes native libraries for OCR, image rendering, and PDF rasterization. These may allocate unmanaged memory, which is not visible to the .NET garbage collector — further increasing pressure on memory in 32-bit environments.

• Even if your documents are small, concurrent OCR operations (multi-threading or async) can spike memory usage quickly.

• If changing architecture is not possible, consider breaking large documents into smaller chunks and use lower resolution. However, this may come with an expense of performance and accuracy trade-off
• IronOCR team is currently investigating in bringing stable support for 32-bit projects.

---

✅ Summary