Detecting and adding form fields to a PDF document

Scanned forms — tax filings, healthcare intake sheets, lease agreements, expense reports — usually arrive as image-based PDFs. The page shows boxes, checkboxes, and signature lines, but the PDF has no AcroForm structure behind them, so end users can’t fill the form in a viewer and downstream tools can’t read the values. Adding those fields by hand means measuring rectangles for every blank on every page.

This sample shows how to detect form-field regions on each page of a document and add matching AcroForm fields automatically using Nutrient .NET SDK. The input can be any document format the SDK supports. If the input isn’t already a PDF, the SDK converts it to PDF when you create the editor.

How Nutrient helps

Nutrient .NET SDK handles the full detection-and-creation pipeline behind a single method call. The SDK takes care of:

• Implicitly converting non-PDF inputs (images, multi-page TIFFs, Office documents) to PDF when the editor is created
• Rendering each PDF page to a bitmap at the resolution the detection model expects
• Running the form-field detection model and classifying each region as text, checkbox, or signature
• Mapping image coordinates back to PDF page coordinates (including the Y-axis flip)
• Adding a matching AcroForm widget for each detected region with a unique field name

The result is a standard PDF with interactive form fields that any viewer can fill or any downstream tool can read.

Supported field types and limits

The current detection model classifies regions into three types: text, checkbox, and signature. The SDK maps them to PdfTextField, PdfCheckBoxField, and PdfSignatureField respectively. Radio buttons aren’t yet emitted by the model and are skipped. Detection runs on the rendered page image, so accuracy depends on the visual quality of the original document — clean scans produce better results than heavily compressed or skewed pages.

Preparing the project

Import the Nutrient namespace:

using Nutrient;

Detecting and adding form fields

The sample opens the source document with a using statement(opens in a new tab), creates a PDF editor, and calls DetectAndAddFormFields() to process every page in a single call. The using statements release the native handles automatically when the block ends, even if an error is thrown:

try
{
    using Document document = Document.Open("input_forms_detection.pdf");
    using PdfEditor editor = PdfEditor.Edit(document);
    editor.DetectAndAddFormFields();

PdfEditor.Edit(document) attaches an editor to the open document. If the document isn’t already a PDF, the SDK converts it to PDF at this step so the rest of the pipeline works on a uniform page representation. Calling editor.DetectAndAddFormFields() walks every page, runs detection, and adds an AcroForm widget for each detected region. Existing form fields on the document aren’t removed — detection only adds new fields and synthesizes unique names so it doesn’t collide with anything already present.

Saving the result

Save the modified document to a new file. The catch block surfaces any licensing, model-loading, or I/O issue that the SDK reports through a NutrientException:

    editor.SaveAs("output.pdf");
    Console.WriteLine("Successfully detected and added form fields");
}
catch (NutrientException e)
{
    Console.Error.WriteLine($"Error: {e.Message}");
    Environment.Exit(1);
}

Conclusion

The workflow for auto-populating an image-based form is:

1. Open the source document.
2. Create a PdfEditor for the document.
3. Call DetectAndAddFormFields() to detect and add fields across every page.
4. Save the result — the using statements release the handles.

The output is a standard PDF with interactive form fields, so existing PDF viewers can fill the form and downstream tools can read the values without any extra configuration.