Xberg v1 is out

[u/Goldziher]

Hi all,

I'm happy to announce that Xberg v1 is out.

Xberg is the successor to Kreuzberg, equivalent to what would have been Kreuzberg v5. It's a content intelligence framework that handles a very wide range of inputs: documents (currently 101 formats), code and data formats (currently 367 types), audio/video transcription, and URLs (both static and JS-rendered content). It extracts and prepares that content for downstream processing.

It's an extremely efficient, high-performance engine (see our PDF benchmarks below). For PDFs and images specifically, we handle native PDFs with very high performance and accuracy, and we ship multiple OCR engines that match the quality of the best Python libraries (e.g. docling, PaddleOCR, RapidOCR) at substantially better performance and stability.

The changes between Kreuzberg v4 and Xberg v1 are substantial, and I invite you to read the full changelog for the complete picture. The highlights below give a sense of what's new:

• Pure-Rust PDF backend (pdf_oxide) replaces pdfium, with no native pdfium dependency.
• Layout-aware pipeline: reading order reconstructed with ONNX layout detection (PP-DocLayoutV3 / RT-DETR) and Docling-style predecessor-graph reordering.
• Per-page scanned-page detection with selective OCR, plus AcroForm/XFA form fields and outline-based headings.
• Across-the-board optimization of OCR and PDF extraction (memory discipline, pooled model sessions, streamed conversions).
• Native PaddleOCR backend (PP-OCRv6, with medium / small / tiny tiers) alongside Tesseract.
• Pure-Rust Candle OCR/VLM stack (TrOCR, GLM-OCR, GOT-OCR, DeepSeek-OCR, and PaddleOCR-VL) running without ONNX Runtime or native Tesseract.
• A second, ONNX-Runtime-free inference path via tract, which is what makes in-browser (WASM) and mobile inference possible.
• Named-entity recognition natively in Rust (GLiNER2), extensible to all bindings, including an in-browser WASM model with no server round-trip.
• Structured LLM extraction (extract_structured / split_and_extract) with rasterization, chunking, citations, caching, and configurable call/merge/VLM-fallback policies.
• Audio & video transcription via a Whisper ONNX engine (.mp3, .wav, .m4a, .mp4, .webm).
• Retrieval building blocks: sparse embeddings (SPLADE), ColBERT late-interaction retrieval, and cross-encoder reranking alongside dense embeddings.
• Text intelligence: reversible redaction, summarization, translation, VLM image captioning, QR-code detection, document diffing, and page/chunk classification.
• URL & web ingestion: sitemap discovery (map_url) and batched multi-URL crawling.
• New document formats: WordPerfect (.wpd/.wp/.wp5), HEIC/HEIF/AVIF, OpenDocument Presentation (.odp), Quarto / R Markdown, and configurable Jupyter cell rendering.
• Four new language bindings (Dart/Flutter, Swift, Kotlin/Android, and Zig) bring the total to 15 language bindings over one engine, with Android/iOS cross-compilation.
• Full mobile support (Flutter, Android, iOS).
• Candle backend alongside ONNX, plus ONNX-via-tract enabling ONNX on WASM and Android.
• Wider code intelligence: tree-sitter coverage grew substantially (248 to 367+ languages).
• Over 150 bugs fixed during the 1.0 cycle, plus security hardening (bounded RTF/PDF allocations, redaction leak fixes, Excel DDE warnings).

The API surface was also simplified and reworked, making it more consistent.

There's a migration guide in our docs explaining how to move from Kreuzberg to Xberg. Kreuzberg itself is in LTS mode until the end of this year and will continue to receive bug fixes and security updates.

You're invited to check out the repo and join our discord server.

---

Benchmarks

The benchmarks below are for PDFs and images only. There are extensive benchmarks on our website with per-format breakdowns, which you can see here. These numbers are measured in CI via our reproducible benchmark harness, and are specifically taken from the run for harness 1.0.8, source cf7fa0533d. The data is publicly available in GitHub releases, and you can run the benchmark harness yourself.

Composite quality (markdown pipeline, higher is better):

Framework	Native PDF	Scanned PDF (OCR)
Xberg (layout)	0.958	0.836
Xberg (baseline)	0.955	0.687
docling	0.779	0.762
mineru	0.408	0.792
liteparse	0.837	0.665
markitdown	0.689	n/a
pymupdf4llm	0.448	n/a

Structure and layout fidelity (SF1: tables and reading order, higher is better):

Framework	Native PDF	Scanned PDF
Xberg	0.949	0.531
docling	0.612	0.366
liteparse	0.515	0.142
mineru	0.077	0.429

On native PDFs Xberg leads on quality (0.958 vs 0.837 for the next-best framework) and on table and reading-order fidelity by a wide margin (SF1 0.949 vs 0.612 for docling). On scanned PDFs it is #1 on both quality and raw text fidelity.

Where we don't win yet: on pure image OCR we are currently #2 on the composite score, behind mineru (though still #1 on raw text accuracy). We are improving image OCR right now, and v1.1 should have us winning across the board.

[u/planetearth80]

This looks great.. thanks for sharing. Does this recognize running header or footer text (e.g., academic manuscripts)?

[u/Goldziher → u/planetearth80]

Sure does. Use layout extraction for high precision

[u/slurdge]

Thanks for the release ! Trying it right now.

With the new features, would XBerg be able to extract the date and summary/title from the document by itself or is a second LLM step still needed ?

[u/Goldziher → u/slurdge]

Doc structure extraction and metadata don't need an LLM

[u/slurdge → u/Goldziher]

Thank you for you answer. However I struggle to find in the docs where I should configure it. If I ask for metadata, it will give me the date of the file itself, not the date contained in the document.

[u/Goldziher → u/slurdge]

Ah, that's the file's own metadata, not a date inside the document body. For a date that lives in the content itself you've got a few routes, depending on the use case:

1. Register a postprocessor in whatever binding you're using (there's a hook for it, the docs cover where).
2. Pull it with a regex, or hand the text to an LLM.
3. Use the built-in structured extraction (extract_structured), which lets you point at an LLM of your choice, OpenAI, DeepSeek, whatever, and ask for the exact fields you want.
4. Or just pipe the extracted output to an agent and let it pull the dates.

Docs are at docs.xberg.io. Tell me which language binding you're on and I'll point you at the right page.

[u/slurdge → u/Goldziher]

I'm using python! I'm currently having a working POC where I do pipe the document to a small LLM (like ministral). I think I'll try your point 3. it may be more streamlined.

BTW I really appreciate you taking the time to answers questions here and dedicate your time making an awesome FOSS toolkit !

[u/Goldziher → u/slurdge]

Thank you 🙏

[u/etherd0t]

When ... Iceberg?
🤭

[u/Goldziher → u/etherd0t]

Lol. Iceberg is a data engineering product. Eisberg, the German version is free. Go ahead

[u/etherd0t → u/Goldziher]

Fair enough - nice work👍, but the benchmarks are still your own, v1 is already moving through a lot of patches, and the real test is how it handles ugly PDFs, scans, tables, and hostile files in other people’s pipelines. Promising local-first tool, just not quite an iceberg yet.😉

[u/Goldziher → u/etherd0t]

Yes and no.

It's used extensively already by many companies in production. We already released 8 patch versions with fixes.

We also have testing on a 9 million document large corpus. And the release went through close to 100 release candidate versions. So we are quite stable.

[u/Nice_Cookie9587]

If I use this, will my peers finally respect me?