The safest Rust-native PDF 2.0 toolkit for parsing, validating, extracting, and generating modern PDFs.
VibePDF is a pure-Rust PDF library built from the ground up for safety, correctness, and the modern PDF 2.0 era. No C dependencies. No unsafe code in production crates.
⚠️ Status: Pre-alpha (64 passed phases; 169 registered phase specifications; 4840 recorded verified phase tests). The API is still stabilizing and requires evaluation before production use.
These figures are generated from
.vibepdf/phase-registry.toml; runcargo xtask docs generateafter an approved registry change.
use vibepdf_core::{ObjectId, PdfDocument, PdfObject};
fn main() -> Result<(), Box<dyn std::error::Error>> {
let mut document = PdfDocument::new();
let title_id = ObjectId::new(1, 0);
document.objects.insert(
title_id,
PdfObject::LiteralString(b"Hello from VibePDF".to_vec()),
);
println!("{}", document.get_object(title_id).unwrap().type_name());
Ok(())
}The snippet is compile-checked by cargo check -p vibepdf-core --example readme_quickstart. For complete PDF-writing examples, run a phase demo below.
For complete working examples, run any phase demo:
cargo run -p vibepdf-core --example phase_019_demo # View metadata demo
cargo run -p vibepdf-annot --example phase_018_demo # Annotations demo: 28 annotation subtypes (ISO 32000-2 Table 171)
cargo run -p vibepdf-forms --example phase_017_demo # AcroForm fields with appearance streams| Feature | Status | Tests | Phase |
|---|---|---|---|
| PdfObject enum + object model (11 variants) | ✅ | 148 | 001 |
| Lexer / Tokenizer | ✅ | 143 | 002 |
| XRef tables + streams + hybrid | ✅ | 96 | 003 |
| Stream filters (Flate, LZW, ASCII85, etc.) | ✅ | 63 | 003a |
| Document parser + page tree | ✅ | 47 | 004 |
| PDF writer / serializer | ✅ | 61 | 005 |
| Incremental save (append-only) | ✅ | 80 | 005a |
| Content stream operators (90+) | ✅ | 163 | 006 |
| Content normalizer + JSON export | ✅ | 70 | 006a |
| Path builder + stroke/fill | ✅ | 130 | 007 |
| PDF/A-1b validation | 🚧 | — | 023 |
| CCITTFax decode | — | 003a | |
| JBIG2 decode | — | 003a | |
| Lazy/streaming parser | ❌ | — | 041a |
| Linearization (Fast Web View) | ❌ | — | 062 |
| Feature | Status | Tests | Phase |
|---|---|---|---|
| Standard 14 fonts (AFM metrics) | ✅ | 122 | 008 |
| TrueType/OpenType table parsing | ✅ | 107 | 009 |
| Font subsetting (CIDFont Type2) | ✅ | 80 | 010 |
| Text shaping + layout (rustybuzz, cosmic-text) | ✅ | 140 | 011 |
| Complex scripts (Arabic, Hebrew, Devanagari, CJK) | ✅ | 120 | 012 |
| Text extraction pipeline (6 stages) | ✅ | 200 | 012a |
| Text converters (Markdown/HTML/PlainText) | ✅ | 110 | 012b |
| Feature | Status | Tests | Phase |
|---|---|---|---|
| 12 color spaces + ICC profiles | ✅ | 127 | 013 |
| 7 shading types + Type 4 functions | ✅ | 127 | 013 |
| Image formats (JPEG, PNG, TIFF, WebP, JPEG2000) | ✅ | 81 | 014 |
| Image masks + inline images | ✅ | 81 | 014 |
| Blend modes + transparency groups | ✅ | 183 | 015 |
| SVG→PDF conversion (usvg/resvg) | ✅ | 86 | 016 |
| Feature | Status | Tests | Phase |
|---|---|---|---|
| AcroForm (text, checkbox, radio, dropdown) | ✅ | 145 | 017 |
| FDF/XFDF import/export | ✅ | 60 | 017a |
| Legacy XFA→AcroForm conversion (PDF 2.0 deprecated; read/convert only) | ✅ | 68 | 017b |
| AcroForm JS calculator | ✅ | 48 | 017c |
| 28 annotation subtypes (ISO 32000-2 §12.5, Table 171) | ✅ | 156 | 018 |
| Feature | Status | Tests | Phase |
|---|---|---|---|
| Page structure (catalog, pages, page tree) | ✅ | 87 | 019 |
| XMP metadata (Dublin Core + PDF + xmp) | ✅ | 87 | 019 |
| Legacy DocumentInfo compatibility (deprecated in PDF 2.0 except dates) | ✅ | 87 | 019 |
| Feature | Status | Phase |
|---|---|---|
| Outlines / Bookmarks | ✅ | 020 |
| Tagged PDF / PDF/UA (accessibility) | ✅ | 021–022 |
| PDF/A validation (2b, 3b, 4) | ❌ | 023–024 |
| PDF/X validation (print) | ❌ | 025 |
| Digital signatures (PAdES) | ❌ | 026–027 |
| Encryption (AES/R2-R6 compatibility; legacy RC4 read/decrypt) | ✅ | 028 |
| Redaction | ❌ | 029 |
| Charts (151 types) | ❌ | 030–031 |
| Barcodes (QR, DataMatrix, Code128) | ❌ | 032 |
| Math typesetting (LaTeX→PDF) | ❌ | 033 |
| AI document understanding | ❌ | 034–036 |
| HTML→PDF | ❌ | 037 |
| DOCX/XLSX/CSV→PDF | ❌ | 038 |
| CLI tool | ❌ | 044 |
| WASM build | ❌ | 046 |
| Python/Node.js bindings | ❌ | 047–048 |
| C FFI | ❌ | 049 |
VibePDF is organized into 14 component crates:
vibepdf-core — Parser, writer, XRef, filters, content streams, document model
vibepdf-fonts — Font loading, TTF/OTF parsing, text shaping, layout, subsetting
vibepdf-text — Text extraction, CMap resolution, reading order, converters
vibepdf-render — Compositing, blend modes, graphics state, stroke/fill
vibepdf-color — Color spaces, ICC profiles, shading, device-N, functions
vibepdf-images — JPEG/PNG/TIFF/WebP/JPEG2000 decode/encode, masks
vibepdf-forms — AcroForm, FDF/XFDF, legacy XFA conversion, JS calculation engine
vibepdf-annot — 28 annotation types per ISO 32000-2 Table 171 (§12.5)
vibepdf-crypto — PDF encryption/decryption, permissions, crypt filters
vibepdf-meta — Tagged PDF, XMP, structure-tree support
vibepdf-pdfua — PDF/UA-1 and PDF/UA-2 validation helpers
vibepdf-svg — SVG→PDF conversion via usvg/resvg
vibepdf-charts — Chart, diagram, and data-visualization primitives
vibepdf-test-harness — Verification pipeline, vision gates, cross-renderer checks
Crate dependencies flow in one direction: specialized crates depend on vibepdf-core, never the reverse (in production builds).
| Metric | Value |
|---|---|
| Phase status and test evidence | Generated from .vibepdf/phase-registry.toml |
| Rust source files and LOC | Intentionally not hand-maintained; inspect the current source tree |
| Component crates | 14 |
| Unsafe code blocks | 0 in production crates |
| ISO 32000-2 citations | 740 |
Every phase demo goes through a 6-layer verification pipeline:
- Rust assertions — unit + integration tests
- Structural checks — qpdf + pdfcpu validation
- Content fidelity — pdftotext, pdfinfo, pdffonts
- Cross-renderer — pdfium vs Ghostscript vs pdftocairo
- Round-trip — binary comparison + structural reconstruction
- Multimodal vision gate — the multimodal model (e.g., MiniMax-M3, MiMo-V2.5-Pro) uses its own native vision via the
readtool to analyze rendered screenshots. No paid ai-vision MCP / Gemini API call.
- Rust 1.96+
- For verification: qpdf, pdfcpu (optional, enhances validation)
git clone https://github.com/your-org/vibepdf.git
cd vibepdf
cargo build
cargo test --workspacecargo run -p vibepdf-core --example phase_019_demo
# Generates output/phase_019_demo.pdf with metadatacargo test -p vibepdf-test-harness --test render_demos -- --nocaptureVibePDF follows a phase-based development plan with 80+ planned phases/sub-phases covering the full ISO 32000-2 (PDF 2.0) specification plus modern additions (AI integration, WASM, language bindings).
| Quarter | Milestone |
|---|---|
| Q2 2026 | Core engine complete (Phases 001–025) |
| Q3 2026 | PDF/A, signatures, encryption (Phases 026–040) |
| Q4 2026 | Charts, AI, conversion (Phases 041–060) |
| 2027 | Language bindings, CLI, v1.0 release |
| Library | Language | Unsafe Code | PDF 2.0 | Complex Scripts | Forms | Signatures |
|---|---|---|---|---|---|---|
| VibePDF | Rust | None in prod crates | Partial (pre-alpha; see generated status) | Yes (Phase 012) | Partial (AcroForm + legacy XFA conversion) | Planned (Phase 026–027) |
| lopdf | Rust | Some | Partial | No | No | No |
| pdf-rs | Rust | Some | Partial | No | No | No |
| MuPDF | C | Yes | Yes | Yes | Yes | Yes |
| Poppler | C++ | Yes | Partial | Yes | Yes | Verify only |
| iText | Java/C# | N/A | Yes | Partial | Yes | Yes |
Honest pre-alpha disclaimer: Cells claiming "Yes" or "Partial" for VibePDF reflect completed phase scope, not the full ISO 32000-2 surface. PDF/A, PDF/X, signatures, and many advanced/integration phases are still pending; PDF/UA and encryption need continued hardening and corpus validation.
VibePDF is distributed under the VibePDF Community and Commercial License. Community use is free for individuals, nonprofits, open-source projects, education/evaluation, and companies under USD 1,000,000 annual gross revenue. Companies at or above that threshold need a Professional, Enterprise, or Premier commercial license for production use.
VibePDF is source-available commercial software. It is not OSI-approved open source. It is not plain MIT or Apache-2.0 software. Third-party components remain under their own permissive licenses and are listed in THIRD-PARTY-NOTICES.md. GPL/AGPL/LGPL code is not linked into or distributed with production VibePDF.