Xberg: A Rust Document-Intelligence Core With Fifteen Language Bindings
Polyglot document intelligence with a Rust core: extract text, metadata, images, tables, and structured data from 106 formats across 140 file extensions, plus code intelligence for 371 languages. Fifteen bindings, with CLI, REST API, and MCP server.
At a glance
- What is it?
- Xberg extracts text, metadata, images, tables and structured data from 107 document formats and adds code intelligence for 371 languages, exposed through a Rust core, a CLI, a REST API, an MCP server and fifteen bindings. The breadth is real; the interesting question is whether one engine can stay precise across that many surfaces.
- Who is it for?
- Adopt Xberg if your pipeline already has to handle several unrelated formats and you would rather call one engine than assemble PDF, Office, image and source-code readers yourself, and if at least one of the fifteen published bindings matches your runtime. Do not adopt it if you need a single format handled with the deepest possible fidelity, or if your deployment cannot accept the optional OCR and transcription dependencies the README lists.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Xberg targets: one reader instead of a dozen
Most document pipelines start as a stack of unrelated libraries. A PDF parser here, a spreadsheet reader there, an OCR step bolted on when scans appear, a separate code parser when the corpus includes repositories. Each has its own API, its own failure modes and its own metadata model, and the glue between them is where bugs live. Xberg's stated goal is to collapse that stack: point it at a file, a URL, an archive or a source tree, and get back text, tables, metadata and structured data from a single call.
The README frames the audience directly. It lists RAG as a topic, and the pitch is aimed at anyone building retrieval or indexing over mixed corpora, where the input is not guaranteed to be a clean PDF. The repository topics name pdf-extraction, table-extraction, metadata-extraction, text-extraction and rag alongside the binding languages, which tells you the maintainers expect the caller to be an application developer rather than a document-format specialist. If your corpus is uniformly one format and one version, you are not the target user.
Architecture: a Rust core with bindings generated by alef
The README opens with an auto-generated notice: the file is produced by a tool called alef, carries a content hash, and can be regenerated with `alef readme` or checked with `alef verify`. That detail matters more than it looks. It means the fifteen bindings are not fifteen hand-written wrappers maintained in parallel. The core is Rust, and the surrounding packages for Python, Node.js, WASM, Java, Kotlin, C#, PHP, Ruby, Elixir, Dart, Swift, Zig, Go and C FFI are generated from it.
The distribution surfaces confirm the same shape. The core ships on crates.io, the Python package on PyPI, the Node and WASM packages on npm under the `@xberg-io` scope, Java and Kotlin on Maven Central, C# on NuGet, PHP on Packagist, Ruby on RubyGems, Elixir on Hex, Dart on pub.dev, Swift through SPM, and a C FFI target linked from the releases page. Beyond libraries, the README names four ways to run it: as a library, a CLI tool, a REST API, and an MCP server. A Docker image on ghcr.io and a Helm chart for Kubernetes are also listed.
That is a lot of surface area for one project. The upside is that a Python service and a Go service can share the same extraction behaviour. The cost is that every binding has to track the core, and the README does not describe how version skew between a binding and the core is handled.
What the extraction actually covers, and where the boundaries are
The coverage numbers are specific: 107 document formats across 141 file extensions, plus code intelligence for 371 languages. The README groups the formats as PDFs, Office, images, HTML, email, e-books, scientific publications and structured data, with MIME detection and what it calls bounded extraction controls. Six output formats are advertised, though the README excerpt does not enumerate them.
URL handling is a separate mode rather than an afterthought. Point Xberg at an `http(s)` URL and it either fetches and extracts a single document or crawls and follows links, with Auto, Document and Crawl modes routed through a separate engine called crawlberg. Note that this makes crawlberg an external dependency for the URL path, not part of the core.
OCR and transcription appear in the capability line, and the repository topics name pdfium and tesseract. Those are heavyweight native dependencies. The README does not, in the material available here, say whether OCR is compiled in by default or gated behind a feature flag, and that is the first thing to check if you are shipping a small container. The claim of being the fastest and most precise open-source PDF-to-Markdown engine is asserted with a link to a benchmarks page, and the releases list includes entries named after benchmark runs. Treat those numbers as the project's own measurements, not as independently reproduced results.
Getting it running: the entry points the README names
The README links an install section and a CLI reference but the excerpt here does not include the command bodies, so the exact invocation flags cannot be quoted from this material. What can be stated is the shape: the core is a Rust crate named `xberg`, the Python package is `xberg` on PyPI, and the Node and WASM packages are `@xberg-io/xberg` and `@xberg-io/xberg-wasm`. The C# package is `XbergIo.Xberg` on NuGet, and the Java and Kotlin artifacts are `io.xberg:xberg` and `io.xberg:xberg-android` on Maven Central.
For anyone who wants to try it without installing anything, the README links a live demo at docs.xberg.io/demo.html built on WebAssembly, which is the lowest-friction way to check whether a given document extracts the way you expect. The Docker image is published to ghcr.io, and Kubernetes deployment is documented through a Helm chart at docs.xberg.io/guides/kubernetes/. The MCP server is the least conventional entry point and the one worth reading the docs for first, since it implies the engine can be exposed as a tool to a model-driven client rather than called from application code.
Because the README is generated from the core, the binding READMEs are likely to be generated too. Verify the CLI reference on docs.xberg.io rather than relying on the repository front page for exact flags.
The maintenance and versioning cost of fifteen bindings
Recent releases show a fast cadence: v1.1.5 and v1.1.4 landed within roughly a day of each other in September 2026, alongside automated benchmark releases tagged with commit hashes. A project moving that quickly across fifteen published package ecosystems imposes a real upgrade tax. Every binding has its own registry, its own release process and its own lag between a core fix and a usable package.
This is the trade-off the architecture buys. Generated bindings reduce the cost of adding a language, but they do not eliminate the cost of publishing to Maven Central, NuGet, Packagist, RubyGems, Hex, pub.dev, PyPI, npm and crates.io on every release. If you pin a binding version, you are pinning a snapshot of core behaviour too, and the README does not describe a compatibility policy between binding versions and core versions.
On licensing: the project is MIT, which is permissive and short. But the README also references pdfium, tesseract and an embeddings capability, and those components carry their own licences. MIT on the wrapper says nothing about the terms of a native OCR library you link against. That is not a legal opinion, just a reminder that the licence badge covers the repository, not necessarily every dependency in your build.
When Xberg is the wrong tool
The honest limitation is depth versus breadth. An engine that handles 107 formats cannot be the best possible reader for all of them at once. If your product is a PDF viewer that must reproduce exact glyph positioning, or a spreadsheet engine that must preserve formulas and cell formatting, a general extractor that normalises everything into text, tables, metadata and structured output is the wrong layer. Xberg returns content, not a faithful rendering.
The second failure mode is dependency weight. OCR and transcription are listed capabilities, and the topics name tesseract and pdfium. In a constrained environment, such as a small serverless function or a WASM bundle, those native pieces may not be available or may blow the size budget. The README does not, in this excerpt, state which of these are optional at build time, so the only way to know is to read the build documentation.
The third is the crawl path. URL crawling routes through crawlberg, a separate repository. If crawlberg is unavailable or unmaintained, single-document extraction still works but the crawling mode does not. That is a real coupling, and it is worth deciding whether you need it before adopting.
Alternatives and the actual difference in approach
The most direct comparison is Kreuzberg, which the README describes as the predecessor: Xberg is described as the next iteration of Kreuzberg, the same engine rebuilt and rebranded under a fresh v1 line. The difference is not capability but continuity. Kreuzberg carries an LTS designation in its repository name, which suggests a slower, supported line, while Xberg is a fresh v1 with a rapid release cadence. If you need stability over new formats, the older line is the more conservative choice. If you need the current engine, Xberg is where development is happening.
A second comparison is the assembly approach: combine a dedicated PDF library, a separate OCR tool and a code parser. That gives you the best tool for each format and full control over each dependency, at the cost of writing and maintaining the glue, the format detection and the unified output model yourself. Xberg's value proposition is precisely that glue. The decision is whether the glue is your problem or theirs.
A third is a hosted document-AI API. Those remove the dependency-management problem entirely but introduce per-page cost, network latency and a data-egress question. Xberg runs locally, which matters if the documents cannot leave your infrastructure. The README's Kubernetes and Docker entries point at self-hosted deployment as a first-class path.
Who should adopt Xberg, and what to verify first
Adopt it if your corpus is genuinely mixed and your team would otherwise maintain several format readers. The fifteen bindings mean you are unlikely to be blocked by language choice, and the MCP server plus REST API give you options beyond embedding a library. The MIT licence removes most distribution friction for the wrapper itself.
Do not adopt it if you need pixel-faithful rendering of a single format family, or if your runtime cannot carry native OCR and PDF dependencies and the documentation confirms they are mandatory in your build configuration. Do not adopt it on the strength of a speed claim alone. The benchmark link is the project's own, and the releases list shows benchmark runs generated automatically, which is a sign of active measurement rather than independent verification.
Before you commit, verify three things. First, check on docs.xberg.io whether OCR, transcription and the embeddings path are optional features or always compiled in. Second, confirm that the binding version you install matches the core version whose behaviour you evaluated, since the README does not document a compatibility contract. Third, read the crawlberg repository if you intend to use URL crawling, because that mode depends on it. Xberg is a serious piece of infrastructure with an unusually wide format net; the risk is not that it does too little, it is that you adopt more surface than your pipeline needs and inherit the release cadence that comes with it.
Editorial conclusion
Adopt Xberg if your pipeline already has to handle several unrelated formats and you would rather call one engine than assemble PDF, Office, image and source-code readers yourself, and if at least one of the fifteen published bindings matches your runtime. Do not adopt it if you need a single format handled with the deepest possible fidelity, or if your deployment cannot accept the optional OCR and transcription dependencies the README lists. Before committing, verify the binding version you intend to install matches the core version you tested, and confirm on docs.xberg.io which extraction controls are bounded by default. Xberg is MIT licensed, but the README also names pdfium, tesseract and an embeddings path, so check the licence terms of whichever optional components your build actually pulls in.
Community notes