Docling, Unstructured, and their peers are excellent parsers. For a .NET application, adopting one means operating a second stack. LM-Kit.NET runs the whole document pipeline inside your process.
The Python ecosystem parses documents brilliantly. The question for a .NET team is what it costs to reach it from production code.
The Python stack
Docling brings IBM Research layout models with strong table extraction; Unstructured turns files into typed elements at ingestion scale; marker and peers convert fast. MIT cores, managed tiers above, all reached from .NET through a service boundary.
LM-Kit.NET
Parsing, OCR, layout, Markdown conversion, splitting, extraction with per-field confidence, redaction, signatures, and PDF/A on one engine, called as typed .NET methods. No sidecar to deploy, no boundary to serialize across.
The rows that decide real projects, not a feature checklist.
| Dimension | LM-Kit.NET | Python document stacks |
|---|---|---|
| Integration shape | A NuGet package; documents never cross a process boundary | A sidecar service or subprocess, with serialization at the boundary |
| What you operate | Nothing extra: the pipeline ships inside your application | A Python runtime, its dependencies, and container images, patched on their own cycle |
| Parsing to Markdown | PDF, Office, email, and images through one converter with layout understanding | Strong layout and table models; Docling's table extraction is a reference point |
| OCR | Built-in engines plus VLM-driven OCR, on-device | Bundled or external engines, wired per project |
| Beyond parsing | Extraction with confidence, classification, redaction, digital signatures, PDF/A on the same objects | Parsing and chunking; everything downstream is a separate system |
| RAG hand-off | Built-in embeddings, vector store, hybrid retrieval, and citations in the same library | Chunks out; your vector database and retrieval stack come next |
| Type safety | Typed .NET objects end to end | JSON across the service boundary |
| Licensing | Free to build and evaluate; Professional for larger production use | MIT cores (Docling, marker); managed tiers for advanced features (Unstructured) |
These projects move fast and this table reflects our reading at publication. If your team already operates Python services and wants a specific parser's models, that is a sound stack; this page is for .NET teams weighing the cost of adopting one. Corrections are welcome through contact.
One question settles most cases: does the document pipeline live inside your .NET application, or beside it?
Choose the Python stack
Your organization runs Python services as a first-class platform, wants a specific parser's models, and the service boundary is a cost you have already paid.
Choose LM-Kit.NET
You want parsing, extraction, redaction, signatures, and retrieval as typed calls in the codebase you already ship, with one dependency and nothing new to operate.
The full comparison grid, plus the capability pages most relevant to this one. The same engine ships two ways: embedded as LM-Kit.NET, or served as LM-Kit One, the Private AI Application Server.
LM-Kit.NET
