--- title: "Firecrawl AnyDoc Test: 14 Formate lokal parsen" canonical: https://wavect.io/de/blog/firecrawl-anydoc-review/ language: de description: "Firecrawl AnyDoc im Test: 14 Formate lokal parsen, Benchmark prüfen und mit Docling, MarkItDown sowie gehosteter OCR vergleichen." image: "https://wavect.io/img/blog/headers/header_firecrawl-anydoc-review.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min Lesezeit · 10. August 2026 Zuletzt geprüft 10. August 2026 [**Weiter**](/de/blog/pdf-inspector-ocr-routing/) # Firecrawl AnyDoc im Test: 14 Formate zu Markdown für KI-Agenten TL;DR Firecrawl AnyDoc ist eine MIT-lizenzierte Rust-Bibliothek, die vierzehn getestete Office-, OpenDocument-, RTF-, EPUB- und CSV-Formate in einheitliches GitHub-Flavored Markdown umwandelt. Textbasierte PDFs laufen über pdf-inspector. Firecrawl nennt für 100 reale Dokumente einen Median von 4,4 ms und den höchsten Qualitätswert im eigenen Benchmark. Der Korpus ist jedoch nicht öffentlich und ein LLM bewertet die Qualität, deshalb musst du das Ergebnis mit deinen Dateien reproduzieren. AnyDoc ist ein starker lokaler Standard, wenn gemischte Office-Formate, geringe Latenz und Verarbeitung ohne Netzwerktransfer zählen. Es ist keine OCR, keine semantische Feldextraktion, kein Chunker und keine vollständige RAG-Pipeline. Nutze Docling für Scans oder komplexes Layout, MarkItDown für ein breiteres Python-Werkzeug oder Firecrawl Parse, wenn eine verwaltete OCR- und Strukturierungsstufe den externen Dienst rechtfertigt. **Firecrawl AnyDoc ist eine schnelle lokale Bibliothek, die gemischte Office-Dateien zu Markdown konvertiert, aber keine vollständige Plattform für Dokumentenintelligenz.** Das Open-Source-Projekt in Rust führt Word, PowerPoint, Excel, OpenDocument, RTF, EPUB und CSV durch ein gemeinsames Dokumentmodell. Textbasierte PDFs werden an pdf-inspector übergeben. Für RAG-Ingestion, Datei-Uploads in KI-Produkten oder interne Wissensimporte ist das Versprechen klar: eine Abhängigkeit, einheitliches Markdown und kein API-Aufruf für normale Dateien. Unser Urteil nach Prüfung von Code, Benchmark-Methode und Alternativen am 10. August 2026: **AnyDoc verdient einen Pilot mit deinem eigenen Dokumentkorpus, wenn Office-Dateien dominieren und lokale Verarbeitung zählt.** Bei Scans, Handschrift, visuellen Layouts oder typisierter Feldextraktion ist es kein guter Standard. Dieser Test beantwortet gezielt die Kaufentscheidung AnyDoc gegen Docling, MarkItDown oder einen verwalteten Parser. PDF- und OCR-Routing bleibt bewusst bei unserem eigenen pdf-inspector-Beitrag. ## Was ist Firecrawl AnyDoc? **AnyDoc wandelt Dokument-Bytes in ein gemeinsames Strukturmodell um und serialisiert dieses Modell als GitHub-Flavored Markdown.** Das [offizielle Repository mit API-Referenz](https://github.com/firecrawl/anydoc) dokumentiert Schnittstellen für Rust, Node.js, Python, CLI und Browser-WebAssembly. Die Formaterkennung liest Marker im Dateiinhalt, statt nur der Endung zu vertrauen. CSV ist die Ausnahme, weil dieses Format keine eigene Signatur besitzt. | Eingabefamilie | Beispiele | Nützliche Ausgabe | | --- | --- | --- | | Word | DOC, DOCX, DOCM | Überschriften, Listen, Tabellen, Links, Notizen und Inline-Formatierung | | PowerPoint | PPT, PPTX und verwandte Varianten | Folieninhalte, Tabellen, Links, Medienverweise und Sprechernotizen | | Excel | XLS, XLSX, XLSM, XLSB | Einheitliche Markdown-Tabellen aus alten und neuen Arbeitsmappen | | OpenDocument | ODT, ODS, ODP | Derselbe Serializer wie für Microsoft-Formate | | Weitere strukturierte Dateien | RTF, EPUB, CSV | Normalisierter Text ohne Office-Runtime | | Textbasiertes PDF | PDF mit brauchbarer Textebene | Lokales Markdown über pdf-inspector | Die Grenze ist geschäftlich wichtiger als die Formatliste. Eingebettete Assets bleiben als Bytes im Dokumentmodell erhalten, während Markdown sie über Alternativtext oder Verweise abbildet. AnyDoc führt keine OCR aus, interpretiert keine Diagramme, erkennt keine Rechnungsfelder, zerlegt Text nicht für Embeddings und bewertet keine Retrieval-Qualität. Es löst die Konvertierung vor diesen Schritten. ## Was belegt der Benchmark mit 4,4 ms wirklich? **Firecrawl nennt für AnyDoc einen Median von 4,4 ms pro Dokument und einen Qualitätswert von 81 über 14 getestete Formate.** Die [offizielle Veröffentlichung mit Benchmark-Erklärung](https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector) beschreibt 100 reale Dokumente und sechs Alternativen. AnyDoc war im Herstellertest das einzige Werkzeug, das alle 14 Formate abdeckte. | Veröffentlichter Wert | Vertretbare Aussage | Fehlender Nachweis | | --- | --- | --- | | 4,4 ms Median | Der native Pfad hat auf der Testmaschine wenig Verarbeitungsaufwand | Cold Start, Upload, p95 und dein Container | | 81 Punkte Gesamtqualität | Die Ausgabe schnitt bei Vollständigkeit, Struktur, Formatierung und Sauberkeit gut ab | Unabhängige menschliche Prüfung und fachliche Korrektheit | | 100 reale Dokumente | Der Test ist breiter als eine einzige DOCX-Demo | Der Korpus ist nicht öffentlich und seine Verteilung nicht prüfbar | | LLM als Richter mit vertauschter Reihenfolge | Die Methode versucht Positions-Bias zu reduzieren | Übereinstimmung mit Fachprüfern und Kosten kritischer Fehler | | Unterschiedliche Formatabdeckung | Vergleiche pro Format sind aussagekräftiger als ein Gesamtwert | Ein identischer Korpus, den jedes Werkzeug vollständig unterstützt | Behandle das als glaubwürdige Herstellerangabe, nicht als universellen Geschwindigkeitsrekord. Fixiere AnyDoc-Version, Hardware, Warm-up und Stichprobe. Miss p50, p95, akzeptierte Struktur, fehlenden Inhalt, Korrekturminuten und Fehlversuche. Ein Parser, der in Millisekunden fertig ist und eine Finanz-Tabelle beschädigt, ist wirtschaftlich nicht schnell. ## AnyDoc, Docling, MarkItDown oder Firecrawl Parse? | Option | Beste Eignung | Wichtigster Nachteil | | --- | --- | --- | | AnyDoc | Gemischte Office-, OpenDocument-, RTF-, EPUB- und CSV-Dateien, die lokal bleiben sollen | Keine OCR und keine semantische Feldextraktion | | Docling | Scans, Bilder, komplexe PDF-Layouts, Tabellen und ein reichhaltigeres verlustfreies Modell | Mehr Modelle, Abhängigkeiten, Konfiguration und Rechenleistung | | MarkItDown | Python-Teams, die breite Konvertierung, Plugins und optionale Cloud-Dienste wollen | Formatspezifische Abhängigkeiten und unterschiedliche Qualität je Konverter | | Firecrawl Parse | Teams, die verwaltete OCR, Zusammenfassungen oder JSON nach Schema einkaufen | Datentransfer, Vertragsprüfung, Kosten pro Aufruf und dokumentiertes 50-MB-Limit | | Bestehenden Parser behalten | Akzeptanzrate, Kosten und Latenz erreichen das Produktziel bereits | Eine Migration braucht einen nachweisbaren wirtschaftlichen Vorteil | Die [aktuelle Formatdokumentation von Docling](https://docling-project.github.io/docling/usage/supported_formats/) nennt PDF, Office, OpenDocument, EPUB, Bilder, HTML, Markup, Audio und Video. Weitere Teile des Toolkits bieten OCR und strukturierte Exporte. Diese Breite macht Docling für layoutreiche oder multimodale Korpora interessant, aber nicht automatisch zum besseren schlanken Office-Konverter. Die [offizielle MarkItDown-Dokumentation von Microsoft](https://github.com/microsoft/markitdown/blob/main/README.md) beschreibt optionale Format-Abhängigkeiten, OCR über ein Plugin und kostenpflichtige Azure-Pfade für besseres Layout oder strukturierte Extraktion. Das passt zu Python-Produkten mit Bedarf an Erweiterbarkeit. AnyDoc passt besser, wenn du eine enge lokale Bibliothek mit mehreren Sprach-Bindings und einheitlicher Office-Ausgabe willst. Firecrawls [Dokumentation für den verwalteten Parse-Endpunkt](https://docs.firecrawl.dev/features/parse) ergänzt OCR-Modi, Zusammenfassungen und JSON nach Schema. Wähle diesen Weg, wenn verwaltete Ausnahmebehandlung mehr wert ist als die Verarbeitung aller Bytes in deiner Umgebung. Lokale Bibliothek und gehostete API sind unterschiedliche Produkte, auch wenn AnyDoc einen Teil des API-Pfads antreibt. ## Wie gehört AnyDoc in eine KI-Agenten- oder RAG-Pipeline? 1. **Eng annehmen:** Erlaube nur benötigte Formate, begrenze Datei- und entpackte Größe, ersetze Dateinamen und verschiebe Uploads in Quarantäne. 2. **Aus Bytes erkennen:** Vergleiche die angegebene Endung mit AnyDocs Inhaltserkennung. Ein Widerspruch braucht Ablehnung oder einen expliziten Recovery-Pfad. 3. **Isoliert parsen:** Begrenze CPU, Arbeitsspeicher, Verschachtelung und Laufzeit. Öffentliche Uploads gehören nicht in den Webprozess oder neben Credentials. 4. **Herkunft erhalten:** Speichere Hash, Originalformat, Parser-Version, Zeitpunkt, Überschriften, Tabellen und Asset-Verweise. 5. **Markdown validieren:** Prüfe Pflichtabschnitte, Zeichenqualität, Zeilenanzahl, Summen, Links und leere Ausgabe vor der Indexierung. 6. **Ausnahmen routen:** Reine Bild-PDFs und eingebettete Scans gehen an einen freigegebenen OCR- oder Vision-Pfad. Verschlüsselte oder kaputte Dateien landen kontrolliert in Review oder Ablehnung. 7. **Erst nach Abnahme chunken:** Parsing erzeugt Quelltext. Metadaten, Rechte, Embeddings, Retrieval und Antwortzitate bleiben eigene Aufgaben. 8. **Akzeptierte Dokumente messen:** Zähle Gesamtkosten und Prüfzeit, nicht nur Parser-Millisekunden. Für PDFs nutze unseren [Test zu pdf-inspector und OCR-Routing](/de/blog/pdf-inspector-ocr-routing/). Dort gehören native Texterkennung, gemischte Seiten und die Grenze zur OCR hin. Nach akzeptiertem Markdown übernimmt die [RAG-Produktionscheckliste für EU-Unternehmen](/de/blog/rag-production-readiness-checklist-eu/) die Themen Rechte, Retrieval-Evaluation und Antwortzitate. Diese klare Zuständigkeit verhindert Keyword-Kannibalisierung. ## Node.js-Schnellstart mit Produktionsgrenze ``` import { toMarkdownBytes } from "@firecrawl/anydoc" export async function parseAcceptedUpload(file) { enforceUploadLimits(file) const bytes = new Uint8Array(await file.arrayBuffer()) const markdown = await toMarkdownBytes(bytes, file.name) const result = validateDocument(markdown) if (!result.accepted) { return routeForReview(file, result.reasons) } return { markdown, sha256: await hash(bytes), parser: "anydoc@PINNED_VERSION", sourceName: safeDisplayName(file.name) } } ``` `enforceUploadLimits`, `validateDocument`, `routeForReview`, `hash` und `safeDisplayName` sind Anwendungscode, keine AnyDoc-APIs. Halte diese Grenze in Aufwandsschätzungen sichtbar. Die Installation des Parsers ist der kleinste Teil einer zuverlässigen Ingestion-Funktion. ## Wann passt AnyDoc nicht? - **Scans und Fotos:** AnyDoc besitzt kein OCR-Modell. Textbasierte PDF-Unterstützung ändert diese Grenze nicht. - **Visuelle Bedeutung:** Diagramme, Unterschriften, handschriftliche Änderungen und räumliche Formulare brauchen Vision oder Dokumentenverständnis. - **Typisierte Geschäftsfelder:** Eine Rechnung in Markdown umzuwandeln validiert noch keine Lieferanten-, Steuer- oder Summenfelder. - **Perfektes Office-Rendering:** Ziel ist sauberer strukturierter Text, nicht pixelidentische Rekonstruktion. - **Unbegrenzte öffentliche Uploads:** Rust und feste Ressourcenlimits helfen, ersetzen aber keine Sandbox, Queue-Grenzen und Updates. - **Unabhängige Benchmark-Pflicht:** Die veröffentlichten Werte stammen vom Projektteam und aus einem privaten Korpus. OWASPs [Leitfaden zur Upload-Sicherheit](https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html) empfiehlt mehrere Schutzschichten: erlaubte Endungen, Content-Type- und Signaturprüfung, neue Dateinamen, Größenlimits, isolierte Speicherung, Malware-Scanning und gehärtete Parser. Lokale Konvertierung senkt ein Transferrisiko. Sie macht eine fremde Office-Datei nicht vertrauenswürdig. ## AnyDoc in zehn Tagen bewerten 1. **Reale Mischung ziehen:** Wähle mindestens 200 Dokumente über alle relevanten Formate, Sprachen, Altersklassen und Quellen. Ergänze kaputte, verschlüsselte, makrofähige und übergroße Beispiele. 2. **Abnahme definieren:** Markiere benötigte Überschriften, Notizen, Tabellen, verbundene Zellen, Links, Formeln, Seitenbezüge und Assets. 3. **Bestehenden Pfad messen:** Erfasse Akzeptanzrate, p50, p95, Infrastrukturkosten, Prüfminuten und Fallback-Anteil. 4. **Fixierte AnyDoc-Version testen:** Miss dieselben Ergebnisse und trenne Warm-Parsing von Prozessstart und Upload. 5. **Zwei Alternativen vergleichen:** Nutze Docling für den schwierigen visuellen Teil und MarkItDown für gemeinsame Formate. 6. **Grenze angreifen:** Teste falsch benannte, komprimierte, verschachtelte und ressourcenintensive Dateien in der geplanten Sandbox. 7. **Fallback bepreisen:** Zähle OCR-Aufrufe, manuelles Review, Ablehnungen und Fehler beim Nutzer. 8. **Nach akzeptierter Aktion entscheiden:** Veröffentliche nur, wenn Qualität und Sicherheit über dem Gate bleiben und Gesamtkosten oder Latenz sinken. Mit unserem [Kostenmodell pro KI-Agenten-Aktion](/de/blog/ai-agent-cost-per-action-2026/) bleiben Wiederholungen und manuelle Korrektur im Nenner. Wenn Dokumenten-Ingestion zur Produktinfrastruktur wird, kann Wavects [AI Enablement](/de/services/ai-enablement/) den Korpus benchmarken, Routing bauen und Retrieval oder Workflow-Automatisierung anbinden. Die [Twinsoft-AI-Fallstudie](/de/case-studies/twinsoft-ai/) zeigt unseren Umgang mit nachvollziehbarer KI-Ausgabe. Der [Leitfaden zur Technologieauswahl für ein MVP](/de/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) hilft dir zu entscheiden, welche Parser-Stufen du besitzen solltest. ## Häufige Fragen ### Was ist Firecrawl AnyDoc? AnyDoc ist eine MIT-lizenzierte Rust-Bibliothek, die Word, PowerPoint, Excel, OpenDocument, RTF, EPUB und CSV in einheitliches GitHub-Flavored Markdown umwandelt. Es gibt Schnittstellen für Rust, Node.js, Python, CLI und Browser-WebAssembly sowie Unterstützung für textbasierte PDFs über pdf-inspector. ### Führt AnyDoc OCR aus? Nein. AnyDoc verarbeitet maschinenlesbaren Inhalt und textbasierte PDFs. Scans, Fotos und reine Bildseiten benötigen einen eigenen OCR- oder Vision-Pfad. ### Ist AnyDoc schneller als Docling? Im veröffentlichten Firecrawl-Benchmark war AnyDoc mit 4,4 ms Median schneller. Die Werkzeuge decken aber unterschiedliche Probleme ab und der Korpus ist privat. Docling ergänzt OCR, Layout-Modelle und mehr multimodale Formate. Teste beide auf dem Teil, den sie in Produktion übernehmen sollen. ### Soll ich AnyDoc oder MarkItDown verwenden? Wähle AnyDoc für einen kompakten lokalen Parser mit Rust-, Node.js-, Python- und WebAssembly-Schnittstellen über gemischte Office-Formate. Wähle MarkItDown, wenn ein Python-Plugin-Ökosystem, zusätzliche Medien oder optionale Azure-Pfade wichtiger sind. ### Kann AnyDoc vollständig im Browser laufen? Ja. Das WebAssembly-Paket verarbeitet Dokument-Bytes lokal. Große oder fremde Dateien brauchen trotzdem einen Web Worker, klare Limits und einen Ablehnungspfad, damit die Oberfläche reagiert. ### Reicht AnyDoc für RAG? Nein. AnyDoc liefert strukturiertes Markdown. Ein produktives RAG-System braucht zusätzlich Abnahme, Chunking, Metadaten, Rechte, Embeddings, Retrieval-Evaluation, Antwortzitate, Monitoring und Löschung. ## Recherchegrenze *Stand 10. August 2026. Die Benchmark-Werte stammen vom Anbieter und nicht aus Wavect-Messungen. Wir haben Repository, Methodik und offizielle Dokumentation der Alternativen geprüft, aber weder den privaten Korpus erhalten noch ein Security-Audit durchgeführt. Versionen, Formate, API-Limits und Preise können sich ändern. Fixiere und prüfe sie vor dem Einkauf.* ## Fazit AnyDoc entfernt einen überraschend teuren Teil der technischen Kleinarbeit: Für jedes Office-Format einen eigenen Parser und ein anderes Ausgabeformat zu betreiben. Gemeinsames Modell, lokale Ausführung und mehrere Sprach-Bindings machen es zu einem glaubwürdigen Standard für normale Dokument-zu-Markdown-Konvertierung. Die Kaufentscheidung hängt von den Ausnahmen ab. Wenn Scans, visuelle Layouts und typisierte Felder dominieren, brauchst du eine reichhaltigere oder verwaltete Pipeline. Wenn native Office-Dokumente dominieren, teste AnyDoc an den schwierigsten Dateien, isoliere den Parser, erhalte die Herkunft und miss akzeptierte Dokumente. Der schnellste Parser ist der, der gesamte Prüf- und Recovery-Kosten senkt, ohne das Qualitäts-Gate zu schwächen. ## Das könnte dich auch interessieren.. [**pdf-inspector: PDFs vor OCR routen** Verarbeite native, gescannte und gemischte PDFs mit einer seitenweisen Routing-Entscheidung.](/de/blog/pdf-inspector-ocr-routing/) [**AI Enablement oder allgemeine KI-Beratung** Vergleiche eine produktive Implementierung in deiner Infrastruktur mit einem reinen Strategieprojekt.](/de/compare/ai-enablement-vs-generic-ai-consultancy/) Modelle und Infrastruktur ## In diesem Cluster weiterlesen [Mit dem Grundlagenartikel starten**LLMs in der EU selbst hosten: Wann sich Open Weights wirklich rechnen**](/de/blog/self-hosting-llms-eu-cost/) - [Muse Glimmer 30B: Ist Metas lokales Agentenmodell produktionsreif?](/de/blog/muse-glimmer-30b-local-agent-guide/) - [OmniRoute KI-Routing: Setup und Produktions-Checkliste](/de/blog/omniroute-ai-routing-setup/) - [Gemini Robotics 2: Ganzkörpersteuerung und die Pilotentscheidung](/de/blog/gemini-robotics-2-whole-body-control/) - [pdf-inspector im Test: PDFs vor OCR lokal routen](/de/blog/pdf-inspector-ocr-routing/) - [Lokaler multimodaler KI-Coding-Assistent: Sprache, OCR und Datenschutz](/de/blog/local-multimodal-ai-coding-assistant/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 13 min Lesezeit · 10. August 2026 Zuletzt geprüft 10. August 2026 [**Weiter**](/de/blog/pdf-inspector-ocr-routing/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/firecrawl-anydoc-review/#webpage", "@type": "WebPage", "dateModified": "2026-08-10", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-10", "url": "https://wavect.io/de/blog/firecrawl-anydoc-review/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Firecrawl AnyDoc ist eine MIT-lizenzierte Rust-Bibliothek, die vierzehn getestete Office-, OpenDocument-, RTF-, EPUB- und CSV-Formate in einheitliches GitHub-Flavored Markdown umwandelt. Textbasierte PDFs laufen über pdf-inspector. Firecrawl nennt für 100 reale Dokumente einen Median von 4,4 ms und den höchsten Qualitätswert im eigenen Benchmark. Der Korpus ist jedoch nicht öffentlich und ein LLM bewertet die Qualität, deshalb musst du das Ergebnis mit deinen Dateien reproduzieren. AnyDoc ist ein starker lokaler Standard, wenn gemischte Office-Formate, geringe Latenz und Verarbeitung ohne Netzwerktransfer zählen. Es ist keine OCR, keine semantische Feldextraktion, kein Chunker und keine vollständige RAG-Pipeline. Nutze Docling für Scans oder komplexes Layout, MarkItDown für ein breiteres Python-Werkzeug oder Firecrawl Parse, wenn eine verwaltete OCR- und Strukturierungsstufe den externen Dienst rechtfertigt.", "articleBody": " Blog-Übersicht/AI und Agents/Modelle und Infrastruktur Firecrawl AnyDoc im Test: 14 Formate zu Markdown für KI-Agenten TL;DR Firecrawl AnyDoc ist eine MIT-lizenzierte Rust-Bibliothek, die vierzehn getestete Office-, OpenDocument-, RTF-, EPUB- und CSV-Formate in einheitliches GitHub-Flavored Markdown umwandelt. Textbasierte PDFs laufen über pdf-inspector. Firecrawl nennt für 100 reale Dokumente einen Median von 4,4 ms und den höchsten Qualitätswert im eigenen Benchmark. Der Korpus ist jedoch nicht öffentlich und ein LLM bewertet die Qualität, deshalb musst du das Ergebnis mit deinen Dateien reproduzieren. AnyDoc ist ein starker lokaler Standard, wenn gemischte Office-Formate, geringe Latenz und Verarbeitung ohne Netzwerktransfer zählen. Es ist keine OCR, keine semantische Feldextraktion, kein Chunker und keine vollständige RAG-Pipeline. Nutze Docling für Scans oder komplexes Layout, MarkItDown für ein breiteres Python-Werkzeug oder Firecrawl Parse, wenn eine verwaltete OCR- und Strukturierungsstufe den externen Dienst rechtfertigt. Firecrawl AnyDoc ist eine schnelle lokale Bibliothek, die gemischte Office-Dateien zu Markdown konvertiert, aber keine vollständige Plattform für Dokumentenintelligenz. Das Open-Source-Projekt in Rust führt Word, PowerPoint, Excel, OpenDocument, RTF, EPUB und CSV durch ein gemeinsames Dokumentmodell. Textbasierte PDFs werden an pdf-inspector übergeben. Für RAG-Ingestion, Datei-Uploads in KI-Produkten oder interne Wissensimporte ist das Versprechen klar: eine Abhängigkeit, einheitliches Markdown und kein API-Aufruf für normale Dateien. Unser Urteil nach Prüfung von Code, Benchmark-Methode und Alternativen am 10. August 2026: AnyDoc verdient einen Pilot mit deinem eigenen Dokumentkorpus, wenn Office-Dateien dominieren und lokale Verarbeitung zählt. Bei Scans, Handschrift, visuellen Layouts oder typisierter Feldextraktion ist es kein guter Standard. Dieser Test beantwortet gezielt die Kaufentscheidung AnyDoc gegen Docling, MarkItDown oder einen verwalteten Parser. PDF- und OCR-Routing bleibt bewusst bei unserem eigenen pdf-inspector-Beitrag. Was ist Firecrawl AnyDoc? AnyDoc wandelt Dokument-Bytes in ein gemeinsames Strukturmodell um und serialisiert dieses Modell als GitHub-Flavored Markdown. Das offizielle Repository mit API-Referenz dokumentiert Schnittstellen für Rust, Node.js, Python, CLI und Browser-WebAssembly. Die Formaterkennung liest Marker im Dateiinhalt, statt nur der Endung zu vertrauen. CSV ist die Ausnahme, weil dieses Format keine eigene Signatur besitzt. EingabefamilieBeispieleNützliche Ausgabe WordDOC, DOCX, DOCMÜberschriften, Listen, Tabellen, Links, Notizen und Inline-Formatierung PowerPointPPT, PPTX und verwandte VariantenFolieninhalte, Tabellen, Links, Medienverweise und Sprechernotizen ExcelXLS, XLSX, XLSM, XLSBEinheitliche Markdown-Tabellen aus alten und neuen Arbeitsmappen OpenDocumentODT, ODS, ODPDerselbe Serializer wie für Microsoft-Formate Weitere strukturierte DateienRTF, EPUB, CSVNormalisierter Text ohne Office-Runtime Textbasiertes PDFPDF mit brauchbarer TextebeneLokales Markdown über pdf-inspector Die Grenze ist geschäftlich wichtiger als die Formatliste. Eingebettete Assets bleiben als Bytes im Dokumentmodell erhalten, während Markdown sie über Alternativtext oder Verweise abbildet. AnyDoc führt keine OCR aus, interpretiert keine Diagramme, erkennt keine Rechnungsfelder, zerlegt Text nicht für Embeddings und bewertet keine Retrieval-Qualität. Es löst die Konvertierung vor diesen Schritten. Was belegt der Benchmark mit 4,4 ms wirklich? Firecrawl nennt für AnyDoc einen Median von 4,4 ms pro Dokument und einen Qualitätswert von 81 über 14 getestete Formate. Die offizielle Veröffentlichung mit Benchmark-Erklärung beschreibt 100 reale Dokumente und sechs Alternativen. AnyDoc war im Herstellertest das einzige Werkzeug, das alle 14 Formate abdeckte. Veröffentlichter WertVertretbare AussageFehlender Nachweis 4,4 ms MedianDer native Pfad hat auf der Testmaschine wenig VerarbeitungsaufwandCold Start, Upload, p95 und dein Container 81 Punkte GesamtqualitätDie Ausgabe schnitt bei Vollständigkeit, Struktur, Formatierung und Sauberkeit gut abUnabhängige menschliche Prüfung und fachliche Korrektheit 100 reale DokumenteDer Test ist breiter als eine einzige DOCX-DemoDer Korpus ist nicht öffentlich und seine Verteilung nicht prüfbar LLM als Richter mit vertauschter ReihenfolgeDie Methode versucht Positions-Bias zu reduzierenÜbereinstimmung mit Fachprüfern und Kosten kritischer Fehler Unterschiedliche FormatabdeckungVergleiche pro Format sind aussagekräftiger als ein GesamtwertEin identischer Korpus, den jedes Werkzeug vollständig unterstützt Behandle das als glaubwürdige Herstellerangabe, nicht als universellen Geschwindigkeitsrekord. Fixiere AnyDoc-Version, Hardware, Warm-up und Stichprobe. Miss p50, p95, akzeptierte Struktur, fehlenden Inhalt, Korrekturminuten und Fehlversuche. Ein Parser, der in Millisekunden fertig ist und eine Finanz-Tabelle beschädigt, ist", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "offizielle Repository mit API-Referenz", "url": "https://github.com/firecrawl/anydoc" }, { "@type": "WebPage", "name": "offizielle Veröffentlichung mit Benchmark-Erklärung", "url": "https://www.firecrawl.dev/blog/anydoc-and-pdf-inspector" }, { "@type": "WebPage", "name": "aktuelle Formatdokumentation von Docling", "url": "https://docling-project.github.io/docling/usage/supported_formats/" }, { "@type": "WebPage", "name": "offizielle MarkItDown-Dokumentation von Microsoft", "url": "https://github.com/microsoft/markitdown/blob/main/README.md" }, { "@type": "WebPage", "name": "Dokumentation für den verwalteten Parse-Endpunkt", "url": "https://docs.firecrawl.dev/features/parse" }, { "@type": "WebPage", "name": "Leitfaden zur Upload-Sicherheit", "url": "https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html" } ], "dateModified": "2026-08-10", "datePublished": "2026-08-10", "description": "Firecrawl AnyDoc ist eine MIT-lizenzierte Rust-Bibliothek, die vierzehn getestete Office-, OpenDocument-, RTF-, EPUB- und CSV-Formate in einheitliches GitHub-Flavored Markdown umwandelt. Textbasierte PDFs laufen über pdf-inspector. Firecrawl nennt für 100 reale Dokumente einen Median von 4,4 ms und den höchsten Qualitätswert im eigenen Benchmark. Der Korpus ist jedoch nicht öffentlich und ein LLM bewertet die Qualität, deshalb musst du das Ergebnis mit deinen Dateien reproduzieren. AnyDoc ist ein starker lokaler Standard, wenn gemischte Office-Formate, geringe Latenz und Verarbeitung ohne Netzwerktransfer zählen. Es ist keine OCR, keine semantische Feldextraktion, kein Chunker und keine vollständige RAG-Pipeline. Nutze Docling für Scans oder komplexes Layout, MarkItDown für ein breiteres Python-Werkzeug oder Firecrawl Parse, wenn eine verwaltete OCR- und Strukturierungsstufe den externen Dienst rechtfertigt.", "headline": "Firecrawl AnyDoc im Test: 14 Formate zu Markdown", "image": "https://wavect.io/img/blog/headers/header_firecrawl-anydoc-review.svg", "inLanguage": "de", "keywords": "KI-Agenten, Dokumentenverarbeitung", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/firecrawl-anydoc-review/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/firecrawl-anydoc-review/", "wordCount": 1959 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/ai-agents/", "name": "AI und Agents", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/models-infrastructure/", "name": "Modelle und Infrastruktur", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/firecrawl-anydoc-review/", "name": "Firecrawl AnyDoc Test: 14 Formate lokal parsen | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "AnyDoc ist eine MIT-lizenzierte Rust-Bibliothek, die Word, PowerPoint, Excel, OpenDocument, RTF, EPUB und CSV in einheitliches GitHub-Flavored Markdown umwandelt. Es gibt Schnittstellen für Rust, Node.js, Python, CLI und Browser-WebAssembly sowie Unterstützung für textbasierte PDFs über pdf-inspector." }, "name": "Was ist Firecrawl AnyDoc?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. AnyDoc verarbeitet maschinenlesbaren Inhalt und textbasierte PDFs. Scans, Fotos und reine Bildseiten benötigen einen eigenen OCR- oder Vision-Pfad." }, "name": "Führt AnyDoc OCR aus?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Im veröffentlichten Firecrawl-Benchmark war AnyDoc mit 4,4 ms Median schneller. Die Werkzeuge decken aber unterschiedliche Probleme ab und der Korpus ist privat. Docling ergänzt OCR, Layout-Modelle und mehr multimodale Formate. Teste beide auf dem Teil, den sie in Produktion übernehmen sollen." }, "name": "Ist AnyDoc schneller als Docling?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Wähle AnyDoc für einen kompakten lokalen Parser mit Rust-, Node.js-, Python- und WebAssembly-Schnittstellen über gemischte Office-Formate. Wähle MarkItDown, wenn ein Python-Plugin-Ökosystem, zusätzliche Medien oder optionale Azure-Pfade wichtiger sind." }, "name": "Soll ich AnyDoc oder MarkItDown verwenden?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Ja. Das WebAssembly-Paket verarbeitet Dokument-Bytes lokal. Große oder fremde Dateien brauchen trotzdem einen Web Worker, klare Limits und einen Ablehnungspfad, damit die Oberfläche reagiert." }, "name": "Kann AnyDoc vollständig im Browser laufen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nein. AnyDoc liefert strukturiertes Markdown. Ein produktives RAG-System braucht zusätzlich Abnahme, Chunking, Metadaten, Rechte, Embeddings, Retrieval-Evaluation, Antwortzitate, Monitoring und Löschung." }, "name": "Reicht AnyDoc für RAG?" } ] } ```