Choose theme
AI Resources
Xberg
Xberg is a document-extraction engine for preparing files for search, AI and other programs. Its Rust core reads PDFs, Office documents, images, email and other formats, returning text, tables and metadata.
Previously developed as Kreuzberg, it can run through language libraries, a command-line tool, an HTTP service or an MCP server. OCR and further processing are configurable parts of the pipeline. Use this as a first read, not a recommendation. Open the original project before trusting details like terms, limits, privacy, cost, setup, or safety.
What it is
Extraction before the next AI step
Xberg turns files into content and structured results that another application can use. Optional steps include splitting text into passages and producing embeddings for retrieval. It is an extraction component rather than a ready-made document chat workspace.
Why it stands out
One engine behind several language interfaces
Python, TypeScript, Rust, Go, Java and other bindings expose the same core. A team can integrate document processing into its existing application language, while choosing a CLI or server when an embedded library is not the right fit.
Availability
Source, packages and deployment examples
The public repository provides the implementation, tests, example inputs and versioned releases. Installation documentation covers language packages, CLI binaries and Docker images. The project declares MIT; see the main repository for current terms.
Why it matters
What makes it useful
A document collection can contain a PDF report, an emailed attachment and a spreadsheet, even when they all feed the same search tool. Xberg provides a common extraction step for those inputs. Its batch interface accepts multiple files with a shared configuration and per-input overrides, so a scanned file can use different extraction settings from a text document in the same batch.
What to know
Where it fits
Use a language binding inside an application, or the CLI for a file-conversion task. An HTTP service lets another program submit documents; the MCP server exposes extraction and related tools to a compatible agent client. Optional chunking and embeddings prepare material for retrieval, while schema-based extraction can call a local or hosted model to produce structured JSON.
Notable points
What stands out
A passage for a language model can span more than one source page. Xberg's chunk metadata can retain the first and last page when page-boundary information is available. Separate per-page output must be enabled through page extraction. These are different choices: splitting text into smaller passages does not automatically request an array of individual pages. Keeping the available page references gives a search application something to use when returning a reader to the source.
Before using
What to review
Check the installation notes for the chosen language and platform. On x86 processors, the bundled ONNX Runtime features need AVX/AVX2 instructions; ordinary text extraction, Tesseract OCR and chunking have different requirements. Some bindings need additional native runtime setup.
OCR backends and model-based processing have their own downloads and configuration. Local extraction and a hosted-model request are different data paths: the selected provider and features determine what is sent out of the process.
Prebuilt packages and custom Rust builds do not necessarily enable the same features. The documentation lists platform and backend differences, including limits on browser WebAssembly. Match the required formats and processing steps to the package being used.
Reader fit
Who may find it relevant
Developers building document search, ingestion services or agent tools are the clearest audience. A technically comfortable reader can inspect a CLI conversion before integrating a library. The structured result is most useful when an application will consume its tables, page information or processing records; someone who only wants to ask questions in a finished chat interface needs another layer around it.
Editorial note
Why LifeHubber lists it
LifeHubber lists Xberg because its document result includes more than material to index: it can identify pages whose OCR failed while extraction continued. Its OCR-failure records identify a page and whether text remains from native PDF text or embedded images. For a document-search builder, that offers a concrete way to keep readable material while directing review to the pages that failed. The recorded recovered flag means some content is available, not that the failed OCR succeeded. The result can therefore serve as a processing record as well as text to index.
Source links
Source materials
Reader note
Before relying on this entry
LifeHubber lists entries to help readers inspect AI projects, not to endorse them or prove they are safe, suitable, accurate, maintained, or right for a specific use. We do not verify every entry in depth. Before relying on anything listed, review the original materials, terms, privacy practices, limits, and risks that matter for your situation.
More in Ecosystem
Keep browsing this category
Explore more AI ecosystem resources.
Docling
docling-project/docling
A document conversion toolkit with structured text, tables and layout, native chunking for retrieval, Markdown and JSON exports, and local model configuration.
MarkItDown
microsoft/markitdown
A Python tool for converting Office files, PDFs and other inputs to Markdown, with format-specific dependencies, optional vision OCR and a separate MCP server package.
SIE
superlinked/sie
A self-hosted inference server and production cluster for serving retrieval, document conversion, structured output, content-safety, and generation models behind agents through one API, with on-demand loading, SDKs, integrations, and Kubernetes operations tooling.
For project maintainers
Listed here? You can use the badge.
If you maintain a project with a current LifeHubber listing, you may add the optional “Listed on LifeHubber AI Resources” badge to its README, docs, or website. No introduction or permission request is needed.
