← All articles

Filling PDF forms in C#: Telerik and MESCIUS libraries vs a mapping API, in code

The comparisons developers usually read pit one hosted PDF API against another. But for .NET teams there's a third option that's often already on the shelf: commercial document-processing libraries like Telerik Document Processing (bundled with DevCraft) and MESCIUS Documents for PDF (the library formerly known as GrapeCity GcPdf). Both are mature, well-supported, and genuinely good at manipulating PDFs inside your own process.

This is a different architectural choice than picking between APIs: a library runs in your application; an API moves the document pipeline out of it. The cleanest way to see the trade is to implement the same task three times and read the diffs. The task: fill a few fields of a real-world account application form — the kind whose fields are named f1_07[0] — and produce a flattened, sign-ready PDF.

(API shapes below are current as of June 2026 — check each vendor's docs for your version.)

Version 1: Telerik Document Processing (RadPdfProcessing)

using Telerik.Windows.Documents.Fixed.FormatProviders.Pdf;
using Telerik.Windows.Documents.Fixed.Model;
using Telerik.Windows.Documents.Fixed.Model.InteractiveForms;

// The knowledge layer: hand-built by inspecting the PDF field by field,
// re-verified every time the issuer revises the form.
static readonly Dictionary<string, string> TextValues = new()
{
    ["topmostSubform[0].Page1[0].f1_01[0]"] = "Jane Doe",   // applicant name
    ["topmostSubform[0].Page1[0].f1_07[0]"] = "1990-04-12", // date of birth
};

var provider = new PdfFormatProvider();
RadFixedDocument document;
using (var input = File.OpenRead("account-application.pdf"))
    document = provider.Import(input);

foreach (var (name, value) in TextValues)
{
    var field = document.AcroForm.FormFields
        .Where(f => f.Name == name).FirstOrDefault();
    if (field is TextBoxField text)
        text.Value = value;
}

// Checkboxes are a separate ritual — each carries a form-specific
// export value, and radio groups share a single field name.
var consent = document.AcroForm.FormFields
    .Where(f => f.Name == "topmostSubform[0].Page1[0].c1_02[0]")
    .FirstOrDefault();
if (consent is CheckBoxField checkbox)
    checkbox.IsChecked = true;

document.AcroForm.FlattenFormFields(); // available since R2 2021
File.WriteAllBytes("filled.pdf", provider.Export(document));

This is clean, idiomatic code, and Telerik's library does everything asked of it. Note what it contains, though: raw field names as magic strings, a hand-maintained dictionary, and type-switching per field kind.

Version 2: MESCIUS Documents for PDF (formerly GrapeCity GcPdf)

using GrapeCity.Documents.Pdf;
using GrapeCity.Documents.Pdf.AcroForms;

var doc = new GcPdfDocument();
using var fs = File.OpenRead("account-application.pdf");
doc.Load(fs);

// Same shape as Telerik: locate the raw name, cast to the concrete
// field type, set the value. The lookup table is still yours to build.
if (doc.AcroForm.Fields
    .FirstOrDefault(f => f.Name == "f1_07[0]") is TextField dob)
{
    dob.Value = "1990-04-12";
}

doc.Save("filled.pdf");

Different vendor, same architecture. GcPdf is fast, runs anywhere .NET runs (including AWS Lambda), and supports filling and flattening AcroForms. And the program still begins where the library ends: someone opened the PDF in an inspector and worked out, by eye, that f1_07[0] is the date of birth.

Version 3: the same task against a mapping API

var payload = new
{
    template_id = "account_application",
    mapping_id = "intake_default",
    data = new
    {
        applicantName = "Jane Doe",
        dateOfBirth = "1990-04-12",
        consentToTerms = true,
    },
};

using var http = new HttpClient();
http.DefaultRequestHeaders.Authorization = new("Bearer", apiKey);

var res = await http.PostAsJsonAsync(
    "https://api.simplyfill.app/v1/generate/pdf", payload);
var result = await res.Content.ReadFromJsonAsync<GenerateResult>();
// result.DownloadUrl → filled, flattened, sign-ready

The field names are semantic (dateOfBirth, not f1_07[0]) because the mapping — the bridge from human names to raw PDF internals — was generated at upload time: SimplyFill's AI reads each field's visible label and proposes the alias, with a confidence score you review once. The checkbox export value, the flattening pass, and the storage of the output file don't appear in the code because they aren't your code's problem.

What the diffs actually show

The lookup table moved, and changed owners. All three versions need the knowledge that f1_07[0] means date of birth. In versions 1 and 2 that knowledge is a dictionary in your repo, built by hand and silently invalidated whenever the issuer revises the form (why the names are cryptic in the first place). In version 3 it's a versioned server-side object, AI-generated and human-reviewed, with a diff to inspect when the form changes.

The iceberg is outside the snippet. The library versions look complete but aren't production: bulk runs, retries, output storage, signed download links, webhooks, and an audit trail all still need building around them — the build-vs-buy inventory applies to commercial libraries just as much as to open-source ones.

XFA is the silent gate. Both libraries fill AcroForm fields. Many government and institutional forms are XFA, which neither product advertises filling — worth verifying against your actual forms before committing, since SimplyFill flattens XFA to AcroForm at upload.

Where the libraries genuinely win

This wouldn't be a useful comparison if the answer were one-sided, and it isn't:

  • Data never leaves your process. For air-gapped environments or policies that forbid sending documents to any external service, a library is the only option that satisfies the constraint — no API can.
  • No per-document economics. Telerik Document Processing comes with DevCraft at $1,149 per developer per year (as of June 2026); MESCIUS licenses per developer with a free trial. At extreme, stable volume, a flat per-developer cost can beat any usage-based model.
  • You may already own it. If your team holds a DevCraft or MESCIUS license for UI components, the document library is already paid for — a real factor, not a rationalization.
  • Filling is a fraction of what they do. These suites create PDFs from scratch, manipulate Word and Excel files, merge, split, and sign. If your roadmap needs broad document processing, a library earns its seat.

When to choose which

Choose a library (Telerik / MESCIUS) if documents can't leave your infrastructure, you already hold the license, your forms are stable and few (so the hand-built mapping is a one-time cost), or you need general document manipulation well beyond form filling.

Choose a mapping API if the forms are many, institutional, or revision-prone — so mapping dominates your cost — or you'd otherwise be building the storage/webhook/audit shell around the library, or XFA forms are anywhere on the roadmap.

The empirical test takes minutes on each side: time how long it takes to get from "here's the PDF" to "every field has a name my code can use" in your own codebase, then run the same form through the SimplyFill quickstart and compare.