Supported Formats & Parser Families

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

The reference material consulted while preparing these pages is listed in the section bibliography.

Baseline date: 2026-10-12. This page was written against Apache Tika 4.1.0 (the latest release on Maven Central on that date) with the 3.3.x differences noted, Java 21 and later for the examples (Tika 4.x needs Java 17), Spring Boot 4.x on Spring Framework 7 and the Docker image apache/tika:4.1.0. Tika can name the type of almost anything, but it can only read the text, metadata and embedded files of the formats for which a parser exists, and the parsers it ships are grouped into families that share a third-party library, a Maven module and a set of limitations. This page is a guided tour of those families, in the order of the official Supported Document Formats page: what each family covers, which library does the work, which Maven artifact contains it, what it extracts (text, metadata, embedded documents) and what it does not. It also shows how to ask Tika itself which parsers and media types are present, from Java, from the command line and from tika-server, so that you never have to trust a table in a document, including this one.

How a media type is found is in Media Types & Detection; how the parsers are called is in Parser API & AutoDetectParser; the artifacts to put on the class path are in Setup & Installation. The deep internals of the two families that have whole sections on this site are not repeated here: Word and Excel with Apache POI are in Office Files and PDF generation and manipulation with iText, JasperReports and PDFBox are in PDF Generation.

All commands and programs on this page were run against Tika 4.1.0 (tika-core, tika-parsers-standard-package as a pom dependency, tika-serialization for TikaLoader, and the tika-app 4.1.0 classes for the command-line listings). The sample files are small stand-ins generated for this page: the one-heading manuscript.docx and one-page catalogue.pdf used on the other pages, plus a book-cover.jpg and book-cover.png (64 by 48 pixels), a publisher-email.eml with catalogue.pdf attached, a samples.zip holding the two files, a minimal novel.epub, a reviews-es.html in UTF-8, and a few small extras (CSV, RSS, RTF, mbox, a gzip file, a Java source and a class file). Where a result depends on a heuristic, the page says so.

Detecting is not parsing

Tika separates two questions that are often confused. The detector answers "what is this?" and it knows far more types than the parsers do: the registry contains well over a thousand media types, the parsers of the standard set declare 258 of them (counts measured on 4.1.0, below). The parser answers "what is in it?", and it exists only for some of those types.

Situation What AutoDetectParser does

A parser exists for the detected type

It runs that parser; the output is XHTML events, metadata and, for containers, embedded documents.

The type is known but no parser is registered

It uses EmptyParser: no text, no exception, and the metadata contains only what detection produced.

The type is application/octet-stream (nothing matched)

The same as above: there is no parser for it.

The type is known and a parser exists, but the tool the parser needs is missing (Tesseract, ffmpeg)

The parser advertises no types, so the file falls through to the previous two rows.

The consequence for an intake service like Bookshelf is that "parsed without an error" does not mean "text was extracted". Check the type, the tk:parsed-by list and whether the content is empty before treating a file as indexed. The official page says it plainly: a type missing from the list is still identified by content detection, but it has no parser, and tika-app or tika-server returns metadata only.

The next program feeds Tika two files whose type it recognises but cannot parse with the standard package: a SQLite header (the SQLite parser lives in an extended package, see Packages: standard, extended and ml) and an EBML (Matroska or WebM) header.

import java.io.ByteArrayInputStream;
import java.nio.charset.StandardCharsets;
import org.apache.tika.io.TikaInputStream;
import org.apache.tika.metadata.Metadata;
import org.apache.tika.metadata.TikaCoreProperties;
import org.apache.tika.parser.AutoDetectParser;
import org.apache.tika.parser.ParseContext;
import org.apache.tika.parser.ocr.TesseractOCRParser;
import org.apache.tika.sax.BodyContentHandler;

public class DetectedButNotParsed {

    public static void main(String[] args) throws Exception {
        System.out.println("Tesseract advertises: "
                + new TesseractOCRParser().getSupportedTypes(new ParseContext()));

        byte[] sqlite = new byte[512];
        byte[] magic = "SQLite format 3\0".getBytes(StandardCharsets.ISO_8859_1);
        System.arraycopy(magic, 0, sqlite, 0, magic.length);
        byte[] ebml = {0x1A, 0x45, (byte) 0xDF, (byte) 0xA3, (byte) 0x9F, 0x42, (byte) 0x86, (byte) 0x81, 0x01,
                0x42, (byte) 0xF7, (byte) 0x81, 0x01, 0x42, (byte) 0xF2, (byte) 0x81, 0x04, 0x42, (byte) 0xF3,
                (byte) 0x81, 0x08, 0x42, (byte) 0x82, (byte) 0x84, 'w', 'e', 'b', 'm'};

        for (byte[] data : new byte[][] {sqlite, ebml}) {
            Metadata metadata = new Metadata();
            BodyContentHandler handler = new BodyContentHandler(-1);
            try (TikaInputStream in = TikaInputStream.get(new ByteArrayInputStream(data))) {
                new AutoDetectParser().parse(in, handler, metadata, new ParseContext());
            }
            System.out.println("type=" + metadata.get("Content-Type")
                    + " parsedBy=" + String.join(",", metadata.getValues(TikaCoreProperties.TIKA_PARSED_BY))
                    + " text=[" + handler.toString().strip() + "]");
        }
    }
}

Output (on a machine without Tesseract on the PATH):

Tesseract advertises: []
type=application/x-sqlite3 parsedBy=org.apache.tika.parser.EmptyParser text=[]
type=application/x-matroska parsedBy=org.apache.tika.parser.EmptyParser text=[]

Two facts are visible here. First, an unparsed file is not an error, so a pipeline must test for it. Second, TesseractOCRParser is on the class path but advertises no media types until the tesseract binary is found, so a Docker image without it quietly leaves scanned images unprocessed (covered in the OCR part of OCR, vision models and natural language processing below).

Source: Supported Document Formats, Tika 4.1.x docs and EmptyParser, Javadoc 4.1.0.

Packages: standard, extended and ml

Tika 4.x ships parsers in three groups of artifacts. The module and package names below were read from the 4.1.0 POMs on Maven Central and from the jars on the class path of the examples.

Artifact Contains Notes

tika-parsers-standard-package (<type>pom</type>)

The 17 tika-parser-*-module artifacts listed below, plus tika-core's own detectors and the encoding and language components it pulls in.

What tika-app, tika-server and the Docker image use. Add it as a pom dependency and Maven resolves every module. Setup details are in Setup & Installation.

tika-parsers-extended (parent) with tika-parser-sqlite3-package and tika-parser-scientific-package

SQLite3 (SQLite3Parser), and the scientific parsers GDALParser, GeographicInformationParser (ISO 19139), GribParser, HDFParser, ISArchiveParser (ISA-Tab) and NetCDFParser.

Heavy native or scientific dependencies. The official page says they are not in tika-app. Add the package you need as a separate dependency.

tika-parsers-ml (parent) with tika-parser-nlp-package, tika-parser-tess4j-module, tika-vlm, tika-inference, tika-transcribe-aws

Named entity recognition, journal and clinical text parsers, in-process Tesseract (Tess4J), vision-language model parsers and the inference bindings, speech-to-text through Amazon Transcribe.

Need models, a service or credentials. Not in the standard set. The 4.1.0 tika-app and tika-server-standard POMs do declare tika-vlm and tika-inference, so those two ship with the distributions (see VLM Parsers & Inference); the other ml modules do not.

The standard modules and the parsers they carry were measured by asking DefaultParser for its component parsers and printing the jar each class came from (program in Listing parsers from Java).

Module artifact (4.1.0) Parsers Contents

tika-parser-apple-module

5

IWorkPackageParser, IWork13PackageParser, IWork18PackageParser, PListParser, AppleSingleFileParser

tika-parser-audiovideo-module

11

AudioParser, MidiParser, Mp3Parser, MP4Parser, FlacParser, OggParser, OpusParser, SpeexParser, VorbisParser, TheoraParser, FLVParser

tika-parser-cad-module

3

DWGParser, DGN8Parser, PRTParser

tika-parser-code-module

6

SourceCodeParser, ClassParser, ExecutableParser, UniversalExecutableParser, MatParser, SAS7BDATParser

tika-parser-crypto-module

2

Pkcs7Parser, TSDParser

tika-parser-font-module

2

TrueTypeParser, AdobeFontMetricParser

tika-parser-html-module

1

JSoupParser

tika-parser-image-module

10

ImageParser, JpegParser, TiffParser, RawTiffParser, WebPParser, PSDParser, JXLParser, ICNSParser, HeifParser, BPGParser

tika-parser-mail-module

2

RFC822Parser, MboxParser

tika-parser-microsoft-module

17

OfficeParser, OOXMLParser, OldExcelParser, WordMLParser, Word2006MLParser, SpreadsheetMLParser, RTFParser, OneNoteParser, ChmParser, ActiveMimeParser, WMFParser, EMFParser, TNEFParser, OutlookPSTParser, PSTMailItemParser, JackcessParser, MSOwnerFileParser

tika-parser-miscoffice-module

11

OpenDocumentParser, FlatOpenDocumentParser, WordPerfectParser, QuattroProParser, EpubParser, IDMLParser, MIFParser, HwpV5Parser, GeoGebraParser, DIFParser, DBFParser

tika-parser-news-module

2

FeedParser, IptcAnpaParser

tika-parser-ocr-module

1

TesseractOCRParser (advertises types only when Tesseract is installed)

tika-parser-pdf-module

1

PDFParser

tika-parser-pkg-module

5

CompressorParser, PackageParser, ZipParser, SevenZParser, RarParser

tika-parser-text-module

2

TextAndCSVParser, MarkdownParser

tika-parser-webarchive-module

3

WARCParser, WACZParser, HttpParser

tika-parser-xml-module

5

DcXMLParser, FictionBookParser, XLIFF12Parser, XLZParser, TMXParser

That is 89 component parsers (88 without the Tesseract parser, which is the number --list-parsers printed for the tika-app classes). The module names are not always intuitive: SAS7BDATParser and MatParser live in the code module, and EpubParser, DBFParser, DIFParser and GeoGebraParser in miscoffice, so search by class name rather than by guessing the module. Shared helper artifacts (tika-parser-zip-commons, tika-parser-mail-commons, tika-parser-xmp-commons, tika-parser-digest-commons, tika-parser-datauri-commons) appear on the class path too but contain no parsers of their own that are listed.

flowchart TB std["tika-parsers-standard-package (pom)"] std --> mods["17 tika-parser-*-module artifacts (89 parsers)"] std --> core["tika-core: detectors, DefaultParser, EmptyParser"] ext["tika-parsers-extended"] --> sql["tika-parser-sqlite3-package"] ext --> sci["tika-parser-scientific-package"] ml["tika-parsers-ml"] --> nlp["tika-parser-nlp-package"] ml --> tess["tika-parser-tess4j-module"] ml --> vlm["tika-vlm and tika-inference"] ml --> aws["tika-transcribe-aws"] app["tika-app and tika-server"] -.->|"ship"| std app -.->|"do not ship"| ext app -.->|"ship"| vlm app -.->|"do not ship"| nlp app -.->|"do not ship"| tess app -.->|"do not ship"| aws

Source: Supported Document Formats, Tika 4.1.x docs, tika-parsers-extended 4.1.0 POM and tika-parsers-ml 4.1.0 POM.

Listing parsers from Java

DefaultParser is the composite that discovers every parser on the class path through the ServiceLoader (META-INF/services/org.apache.tika.parser.Parser). AutoDetectParser wraps it, so asking an AutoDetectParser for its parsers returns the single DefaultParser; ask DefaultParser for the components instead.

import java.net.URISyntaxException;
import java.nio.file.Path;
import java.util.ArrayList;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.TreeMap;
import org.apache.tika.mime.MediaType;
import org.apache.tika.parser.AutoDetectParser;
import org.apache.tika.parser.DefaultParser;
import org.apache.tika.parser.ParseContext;
import org.apache.tika.parser.Parser;

public class ListParsers {

    public static void main(String[] args) throws URISyntaxException {
        ParseContext context = new ParseContext();
        DefaultParser defaults = new DefaultParser();

        Set<MediaType> types = new AutoDetectParser().getSupportedTypes(context);
        List<Parser> parsers = defaults.getAllComponentParsers();
        System.out.println("media types with a parser: " + types.size());
        System.out.println("component parsers: " + parsers.size());

        Map<String, List<String>> byArtifact = new TreeMap<>();
        for (Parser parser : parsers) {
            String jar = Path.of(parser.getClass().getProtectionDomain().getCodeSource().getLocation().toURI())
                    .getFileName().toString().replace("-4.1.0.jar", "");
            byArtifact.computeIfAbsent(jar, k -> new ArrayList<>()).add(parser.getClass().getSimpleName());
        }
        byArtifact.forEach((jar, names) -> System.out.println(jar + " (" + names.size() + "): " + names));

        Map<MediaType, Parser> byType = defaults.getParsers(context);
        System.out.println("application/pdf -> " + byType.get(MediaType.application("pdf")).getClass().getName());
        System.out.println("xlsx -> " + byType.get(MediaType.application(
                "vnd.openxmlformats-officedocument.spreadsheetml.sheet")).getClass().getName());
        System.out.println("image/tiff has parser: " + byType.containsKey(MediaType.image("tiff")));
    }
}

Output (the per-artifact lines are the ones shown in the table above, shortened here):

media types with a parser: 258
component parsers: 89
tika-parser-apple-module (5): [IWork18PackageParser, IWork13PackageParser, IWorkPackageParser, PListParser, ...]
tika-parser-pdf-module (1): [PDFParser]
tika-parser-pkg-module (5): [ZipParser, SevenZParser, RarParser, PackageParser, CompressorParser]
...
application/pdf -> org.apache.tika.parser.pdf.PDFParser
xlsx -> org.apache.tika.parser.microsoft.ooxml.OOXMLParser
image/tiff has parser: true

getSupportedTypes(ParseContext) takes a context because some parsers change what they accept with the configuration carried by it (OCR, for example). Pass the context you will actually parse with. findDuplicateParsers(context) on a CompositeParser returns the types for which more than one parser competes, which is the tool for diagnosing "the wrong parser handled my file".

Source: DefaultParser, Javadoc 4.1.0 and CompositeParser, Javadoc 4.1.0.

Listing parsers from the command line and the server

The tika-app command line prints the same information. The flags below are the ones in the 4.1.0 --help output; --list-parser-details-adoc is the one the Tika project uses to regenerate the full table at the bottom of its formats page.

Flag Prints

--list-parsers

The parser tree: AutoDetectParser, CompositeParser, DefaultParser and each component class.

--list-parser-names

Tab-separated class name and friendly name. The friendly names (pdf-parser, ooxml-parser, jsoup-parser) are the kebab-case keys used in tika-config.json.

--list-parser-details

Each parser followed by the media types it supports.

--list-parser-details-apt

The same, in the APT format.

--list-parser-details-adoc

The same, in AsciiDoc.

--list-detectors, --list-detector-names

The detectors, see Media Types & Detection.

--list-supported-types

Every media type known to the registry, with aliases and the supertype.

--list-met-models

The metadata models and their keys.

 
java -jar tika-app-4.1.0.jar --list-parsers | head -8
java -jar tika-app-4.1.0.jar --list-parser-names | head -4
java -jar tika-app-4.1.0.jar --list-parser-details | grep -A3 "PDFParser"
java -jar tika-app-4.1.0.jar --list-supported-types | grep -c '^[a-z]'

Output (the commands were run with the 4.1.0 tika-app classes on the same class path as the Java examples, because the thin tika-app jar from Maven Central has no dependencies; the distribution zip from the download page does):

   org.apache.tika.parser.AutoDetectParser (Composite Parser):
      org.apache.tika.parser.CompositeParser (Composite Parser):
         org.apache.tika.parser.DefaultParser (Composite Parser):
            org.apache.tika.parser.apple.AppleSingleFileParser
            org.apache.tika.parser.apple.PListParser
            org.apache.tika.parser.asm.ClassParser
            org.apache.tika.parser.audio.AudioParser
            org.apache.tika.parser.audio.MidiParser
org.apache.tika.parser.apple.AppleSingleFileParser	apple-single-file-parser
org.apache.tika.parser.apple.PListParser	p-list-parser
org.apache.tika.parser.asm.ClassParser	class-parser
org.apache.tika.parser.audio.AudioParser	audio-parser
1687

The last number is the count of top-level lines printed by --list-supported-types on this class path; use it as an order of magnitude (well over a thousand known types, against 258 with a parser), not as an exact figure that is promised to stay constant between releases.

On a running tika-server (see Introduction & Architecture for the module map) the same information is available over HTTP, and it is the only way to see what a deployed image contains:

curl -s http://localhost:9998/parsers            # registered parsers
curl -s http://localhost:9998/parsers/details    # parsers with their supported media types
curl -s http://localhost:9998/detectors          # registered detectors
curl -s http://localhost:9998/mime-types         # known media types
curl -s http://localhost:9998/version

The 4.1.x server page lists these as the endpoints parsers, detectors, mime-types and version; leaving the endpoints list unset enables all of them (except status, which is opt-in). They were not run for this page (no server was started), so the exact response layout is unverified here: request Accept: application/json and inspect it. In a hardened deployment you may want to list only the endpoints the clients need, which removes the discovery endpoints from the surface.

Source: Tika 4.1.x docs, Command Line, Tika 4.1.x docs, Tika Server and Supported Document Formats.

The format-family table

The table summarises the families of the 4.1.x formats page. Text means body text in the XHTML output, metadata means entries in the Metadata object, embedded means that the parser hands child documents back to the parser context (see Embedded Documents & Recursive Parsing). The extraction columns state what the official page says the parsers do, confirmed where possible by the runs in the next section.

Family Parsers Library (from class path) Extracts Notes

HTML

JSoupParser

jsoup

Text, metadata

Output is well-formed XHTML; heuristics keep inline scripts out of the text.

XML

DcXMLParser, FictionBookParser, plus the vocabulary parsers below

not checked

Text, Dublin Core metadata

The default parser ignores the structure and keeps only the text and the Dublin Core elements.

Microsoft Office

OfficeParser, OOXMLParser, OldExcelParser, WordMLParser, Word2006MLParser, SpreadsheetMLParser, OneNoteParser, MSOwnerFileParser

Apache POI

Text, metadata, embedded objects

OLE2 and OOXML. See File Formats: OOXML and OLE2.

OpenDocument

OpenDocumentParser, FlatOpenDocumentParser

not checked

Text, metadata, embedded

Packaged ODF and OpenOffice 1.0, and the flat .fodt, .fods, .fodp variants.

iWork

IWorkPackageParser, IWork13PackageParser, IWork18PackageParser

not checked

Text (original package), metadata, preview image

The 2013 and 2018 generations extract metadata, embedded resources and the preview, not the body text.

WordPerfect

WordPerfectParser, QuattroProParser

not checked

Text, metadata

WP6 and later; QuattroPro QPW v9 and later.

PDF

PDFParser

Apache PDFBox

Text, metadata, embedded files, inline images, annotations, forms

Can hand pages or images to OCR or a vision model. See iText Text Extraction and Parsing for the PDF side.

EPUB and FictionBook

EpubParser, FictionBookParser

not checked

Text, metadata

Metadata uses dc: and epub: keys.

RTF

RTFParser

not checked

Text, metadata, embedded objects

The 3.x formats page described a Swing-based parser; the 4.1 page lists RTFParser.

Compression and packaging

CompressorParser, PackageParser, ZipParser, SevenZParser, RarParser, AppleSingleFileParser, PListParser

Commons Compress, junrar

Entry names as text, metadata, embedded

Every entry is passed to a second parsing stage.

Text and CSV

TextAndCSVParser, MarkdownParser

Commons CSV, commonmark

Text, tables for CSV and TSV

Runs the encoding detectors; Markdown is parsed into structured XHTML.

Feeds

FeedParser, IptcAnpaParser

ROME

Text, metadata

RSS and Atom; the IPTC ANPA news wire format.

Web archives

WARCParser, WACZParser, HttpParser

jwarc

Metadata, each captured response as an embedded document

HttpParser handles a single raw HTTP response.

Help

ChmParser

not checked

Text, metadata

Compiled HTML help.

Audio

AudioParser, MidiParser, Mp3Parser, MP4Parser, FlacParser, OggParser, OpusParser, SpeexParser, VorbisParser

javax.sound, vorbis-java

Metadata (text for lyrics)

Rates, channels, artist, title.

Image

ImageParser, JpegParser, TiffParser, RawTiffParser, WebPParser, PSDParser, JXLParser, HeifParser, ICNSParser, BPGParser, WMFParser, EMFParser

javax.imageio, metadata-extractor

Metadata (Exif, IPTC, XMP); text only from WMF and EMF

No text from pixels without OCR.

Video

FLVParser, MP4Parser, OggParser, TheoraParser

not checked

Metadata

Frames and transcoding need ffmpeg through the external parser.

Java and source

ClassParser, SourceCodeParser, PackageParser (jars)

ASM, jhighlight

Class names and signatures, formatted source, simple metadata

Java, C, C++ and Groovy source.

Mail

RFC822Parser, MboxParser, OutlookPSTParser, PSTMailItemParser, TNEFParser, OfficeParser (MSG)

Apache mime4j, java-libpst, POI

Text, headers as metadata, attachments as embedded

.eml, mbox, .pst, winmail.dat, Outlook .msg.

CAD

DWGParser, DGN8Parser, PRTParser

not checked

Metadata

AutoCAD DWG, MicroStation DGN v8, Cadkey PRT.

Fonts

TrueTypeParser, AdobeFontMetricParser

FontBox

Metadata

Simple font metadata.

Publishing and localisation

IDMLParser, MIFParser, HwpV5Parser, XLIFF12Parser, XLZParser, TMXParser

not checked

Text, metadata

InDesign IDML, FrameMaker MIF, Hangul HWP v5, XLIFF 1.2, TMX.

Scientific

DIFParser, MatParser, GeoGebraParser (standard); GDALParser, GeographicInformationParser, GribParser, HDFParser, ISArchiveParser, NetCDFParser (extended)

jmatio, others

Attribute metadata

The extended ones pull in large native libraries.

Executables

ExecutableParser, UniversalExecutableParser

not checked

Platform, architecture and type metadata

Windows PE, ELF, Mach-O (including universal binaries).

Crypto

Pkcs7Parser, TSDParser

Bouncy Castle

Signed content, metadata

Parses the content of PKCS7 signed messages and Time Stamped Data envelopes.

Databases

JackcessParser, DBFParser, SAS7BDATParser (standard); SQLite3Parser (extended)

jackcess, parso

Tabular content, metadata

Access, dBase and FoxPro, SAS, SQLite3.

OCR and vision models

TesseractOCRParser, Tess4J, the Claude, Gemini and OpenAI parsers

Tesseract, external services

Text from images

Tesseract runs as soon as its binary is found (for example in the -full image); Tess4J and the VLM parsers are opt-in.

Natural language processing

NamedEntityParser, JournalParser, CTAKESParser, GeoParser

OpenNLP, Grobid, cTAKES

Entities added to the metadata

In tika-parsers-ml, need models or services.

Source: Supported Document Formats, Tika 4.1.x docs (family list, parser classes and the statements of what each extracts) and the 4.1.0 module jars (parser-to-module mapping).

What the parsers actually produce

A table of capabilities is easy to over-read, so the next program parses every sample file with a RecursiveParserWrapper and prints, per file, the detected type, the parser classes that ran, the number of embedded documents and the start of the text. The RecursiveParserWrapper returns one Metadata object for the file and one for each embedded document, and its handler type decides the content format, here plain text.

import java.nio.file.Files;
import java.nio.file.Path;
import java.util.List;
import java.util.Optional;
import java.util.stream.Stream;
import org.apache.tika.io.TikaInputStream;
import org.apache.tika.metadata.HttpHeaders;
import org.apache.tika.metadata.Metadata;
import org.apache.tika.metadata.TikaCoreProperties;
import org.apache.tika.parser.AutoDetectParser;
import org.apache.tika.parser.ParseContext;
import org.apache.tika.parser.RecursiveParserWrapper;
import org.apache.tika.sax.BasicContentHandlerFactory;
import org.apache.tika.sax.RecursiveParserWrapperHandler;

public class FormatTour {

    public static void main(String[] args) throws Exception {
        List<Path> files;
        try (Stream<Path> stream = Files.list(Path.of(args[0]))) {
            files = stream.sorted().toList();
        }
        for (Path file : files) {
            RecursiveParserWrapper wrapper = new RecursiveParserWrapper(new AutoDetectParser());
            RecursiveParserWrapperHandler handler = new RecursiveParserWrapperHandler(
                    new BasicContentHandlerFactory(BasicContentHandlerFactory.HANDLER_TYPE.TEXT, -1));
            Metadata metadata = new Metadata();
            try (TikaInputStream in = TikaInputStream.get(file, metadata)) {
                wrapper.parse(in, handler, metadata, new ParseContext());
            } catch (Exception e) {
                System.out.println(file.getFileName() + " FAILED " + e);
                continue;
            }
            List<Metadata> list = handler.getMetadataList();
            Metadata top = list.get(0);
            String text = String.valueOf(top.get(TikaCoreProperties.TIKA_CONTENT)).strip().replaceAll("\\s+", " ");
            String parsers = String.join(",",
                    Optional.ofNullable(top.getValues(TikaCoreProperties.TIKA_PARSED_BY)).orElse(new String[0]));
            System.out.printf("%-20s %-48s %-52s embedded=%d text=\"%s\"%n", file.getFileName(),
                    top.get(HttpHeaders.CONTENT_TYPE), parsers, list.size() - 1,
                    text.length() > 40 ? text.substring(0, 40) + "..." : text);
        }
    }
}

Output, with the package prefix org.apache.tika.parser. removed and the repeated DefaultParser entry dropped for readability (the real output lists DefaultParser first in tk:parsed-by):

Gen.class            application/java-vm        asm.ClassParser            embedded=0 text="Gen public synchronized class Gen { publ..."
Hello.java           text/x-java-source         code.SourceCodeParser      embedded=0 text="Hello.javapublic class Hello { public st..."
archive.mbox         application/mbox           mbox.MboxParser            embedded=2 text="null"
book-cover.jpg       image/jpeg                 image.JpegParser           embedded=0 text="null"
book-cover.png       image/png                  image.ImageParser          embedded=0 text="null"
books.csv            text/plain; charset=windows-1252  csv.TextAndCSVParser embedded=0 text="isbn,title,year 978-1,The Lighthouse Kee..."
catalogue.pdf        application/pdf            pdf.PDFParser              embedded=0 text="Spring catalogue Bookshelf spring catalo..."
catalogue.rss        application/rss+xml        feed.FeedParser            embedded=0 text="New books New books Feed Winter Tides A ..."
legacy.txt.gz        application/gzip           pkg.CompressorParser       embedded=1 text="legacy.txt"
manuscript.docx      application/vnd.openxmlformats-officedocument.wordprocessingml.document
                                                microsoft.ooxml.OOXMLParser,microsoft.ooxml.xwpf.XWPFEventBasedWordExtractor
                                                                           embedded=0 text="The Lighthouse Keeper The Lighthouse Kee..."
notes.rtf            application/rtf            microsoft.rtf.RTFParser    embedded=0 text="Notes Hello Bookshelfreader."
novel.epub           application/epub+zip       epub.EpubParser            embedded=0 text="The Lighthouse Keeper Chapter one It beg..."
publisher-email.eml  message/rfc822             mail.RFC822Parser          embedded=1 text="Spring catalogue Please find our catalog..."
reviews-es.html      text/html; charset=UTF-8   html.JSoupParser           embedded=0 text="Reseñas Reseñas de El farero Una novela ..."
samples.zip          application/zip            pkg.ZipParser              embedded=2 text="manuscript.docx catalogue.pdf"

Reading the output:

  • Images give no text. book-cover.jpg and book-cover.png are parsed (JpegParser, ImageParser), produce a page of img: and tiff: metadata (width, height, compression, resolution) and an empty body. A scanned loan form is the same until OCR is configured.

  • Archives and mail give their structure as text and their content as children. samples.zip shows its entry names as text and two embedded documents; publisher-email.eml has the message body as text and catalogue.pdf as one embedded document; legacy.txt.gz has one embedded document, the decompressed file. The embedded records carry the tk:embedded-resource-path and tk:embedded-resource-type keys (ATTACHMENT for the mail attachment).

  • The title appears twice in manuscript.docx because the OOXML parser emits the title metadata and the heading, and in catalogue.rss for the same reason. Index a field, not the concatenation, if that matters.

  • A name hint changes the parser. Hello.java is parsed by SourceCodeParser only because the stream was created with TikaInputStream.get(file, metadata), which records the file name; without it the file was detected as text/plain and went to TextAndCSVParser. The same applies to the CSV below.

  • books.csv stayed text. The three-line sample was detected as text/csv, but TextAndCSVParser applies the CSV parser only if it detects regularity in the column counts and otherwise treats the file as text. With the same header and 30 generated rows it reported Content-Type: text/csv; charset=windows-1252; delimiter=comma, added the key csv:delimiter and produced an XHTML table with a tr per row. The heuristic is documented in the Javadoc of TextAndCSVParser, which also names the metadata keys NUM_COLUMNS and NUM_ROWS.

  • The ordinary encoding story still applies. The ASCII CSV came back as windows-1252 because the statistical detector had little evidence; the encoding pipeline is described in Character Encoding Detection.

A tiny word of caution on -1 in the handler factory: it removes the write limit, which is acceptable for these generated samples and unacceptable for untrusted input. The limits and the content-format choices are in Content Handlers & Output Formats. A side finding that is relevant to the same program: on 4.1.0, giving RecursiveParserWrapper a handler with a small positive limit (200 characters, tried first) made parsing a zip or an email throw a PropertyTypeException for tk:exception:write-limit-reached when an embedded document hit the limit. This is the behaviour observed on 4.1.0 in a throwaway project; it was not investigated further and should be re-tested, and reported to the Tika project if it reproduces, before relying on small limits together with RecursiveParserWrapper.

Source: RecursiveParserWrapper, Javadoc 4.1.0 and TextAndCSVParser, Javadoc 4.1.0.

Family by family

The sections follow the order of the official page. Each says what to expect from the family, what it does not do and where to go next.

HyperText Markup Language

JSoupParser (module tika-parser-html-module) uses jsoup, so it copes with the broken markup found on the real web and always emits well-formed XHTML. Scripts and styles are kept out of the extracted text. It handles text/html, application/xhtml+xml, application/vnd.wap.xhtml+xml and application/x-asp in the 4.1.0 list. The charset comes from the encoding detectors, which read the <meta> declaration among other evidence. In the Bookshelf tour, reviews-es.html was detected as text/html; charset=UTF-8 and the heading text Reseñas came out intact.

The book (chapter 8) describes the HTML parser of Tika 1.0 as built on TagSoup. In 4.x the 4.1.x page names jsoup (the 3.3.2 page already did). A parser that cleans HTML is not a browser: JavaScript is not executed, so content that a single-page application renders on the client is not in the extracted text.

XML and derived formats

DcXMLParser is the fallback for XML: it keeps the text and ignores the structure, apart from the Dublin Core elements, which become metadata. The vocabularies that deserve more are handled by their own parsers (XHTML, OOXML, ODF, EPUB, RSS, XLIFF, TMX, FictionBook, DIF). If you need the XML structure itself, Tika is the wrong tool; parse it with an XML API.

Microsoft Office

OfficeParser (OLE2: .doc, .xls, .ppt, .msg, .vsd and so on) and OOXMLParser (.docx, .xlsx, .pptx) use Apache POI. The 4.1.x page also lists OldExcelParser (Excel 2, 3 and 4), the older XML formats (SpreadsheetMLParser, WordMLParser, Word2006MLParser), OneNoteParser and MSOwnerFileParser for the ~$document.docx lock files. In the tour, manuscript.docx was parsed by OOXMLParser and, as a second entry in tk:parsed-by, XWPFEventBasedWordExtractor, the SAX-based Word extractor (3.3.2 made the SAX-based OOXML parsers the default, according to the release news on the Tika site).

Tika extracts text, core and extended properties and embedded objects, not layout: it does not reconstruct tables as tables for every format, headers and footers handling depends on the handler, and a protected file needs a password in the ParseContext. POI’s own memory and threading behaviour, the OLE2 and OOXML structures and the streaming APIs are documented in the Office Files section:

POI dependency clashes with your own application are described in Setup & Installation.

OpenDocument, iWork, WordPerfect and similar office suites

OpenDocumentParser reads the packaged ODF formats and the OpenOffice 1.0 predecessor; FlatOpenDocumentParser reads the single-file XML variants. IWorkPackageParser handles the original iWork package; the newer 2013 and 2018 generations are identified by IWork13PackageParser and IWork18PackageParser, which extract metadata, embedded resources and the preview image but, per the official page, not the body text yet. Plan for that gap: a Keynote or Pages file saved by a current Apple application will index as metadata only. WordPerfectParser (WP6 and later) and QuattroProParser (QPW v9 and later) cover Corel formats.

Portable Document Format

PDFParser (module tika-parser-pdf-module) uses Apache PDFBox. It extracts text in reading order, document information and XMP metadata, embedded files, inline images, annotations, forms and the incremental-update history, and it can hand pages or images to OCR or a vision model. In the tour, catalogue.pdf produced the text Spring catalogue and a page of metadata (author, producer, pdf:pdf-version, access-permission:* flags, xmpTPg:NPages) with no embedded documents. What it does not do: it does not recover tables or multi-column semantics (the text is a linear stream), and a scanned PDF has no text layer to extract until OCR is configured. PDF files that carry an XFA form were the subject of CVE-2025-54988, an XML external entity issue in the PDF parser fixed in 3.2.2 according to the Tika security page, and of CVE-2025-66516, which widened it to tika-core: upgrading only the PDF module is not enough, so align tika-core and every module through the BOM. See PDF Parsing and Security for the affected ranges.

The PDF parser’s options (OCR strategy, sorting by position, extractInlineImages, and so on) are configuration and belong to the PDF Parsing and Configuration pages of this section. The structure of PDF itself, text extraction with iText and the standards (PDF/A, PDF/UA) are in:

EPUB and FictionBook

EpubParser reads application/epub+zip (and the iBooks variant application/x-ibooks+zip). In the tour, the minimal novel.epub produced The Lighthouse Keeper Chapter one It begins at dusk. and the Dublin Core metadata dc:title, dc:creator, dc:identifier, dc:language plus epub:version=3.0 and epub:rendition:layout=reflowable. FictionBookParser does the same for the XML .fb2 format. DRM-protected EPUB files cannot be read.

Rich Text Format

RTFParser (package org.apache.tika.parser.microsoft.rtf) extracts text, metadata and embedded objects. In the tour the title from the RTF information group (Notes) and the body came out. The 3.3.2 formats page described the RTF parser as using the javax.swing.text.rtf feature; the 4.1.x page does not repeat that statement. Treat that as a change between the two pages, not a measured benchmark.

Compression and packaging

CompressorParser handles the top-level compression formats (the 4.1.x page lists Gzip, BZip2, XZ, LZMA, Z, Brotli, LZ4 and Snappy); PackageParser and its subclasses ZipParser and SevenZParser unpack archives (Zip, 7Zip, Tar, AR, ARJ, CPIO, Dump, jar); RarParser adds RAR, which Commons Compress does not support. Each entry goes through a second parsing stage using the parser in the ParseContext, which is how a .docx inside a zip is parsed. This is the point where decompression bombs and enormous archives matter: limits on depth, count and size belong with the embedded documents (Embedded Documents & Recursive Parsing). Detection of damaged zips (the "salvaging" behaviour) is in Media Types & Detection.

In the tour samples.zip reported two embedded documents and legacy.txt.gz one. A .tar.gz is two levels: the compressor, then the package.

Text formats

TextAndCSVParser runs the encoding detectors, then decides between text, CSV and TSV, as the previous section showed. MarkdownParser parses Markdown into structured XHTML instead of treating it as plain text. The 3.3.2 page describes TXTParser with ICU-based detection. The encoding pipeline and the Bookshelf legacy-catalogue.txt case are in Character Encoding Detection.

Feeds, web archives and help formats

FeedParser (ROME) reads RSS and Atom: in the tour the channel title and the item text were extracted. IptcAnpaParser reads the IPTC ANPA news wire format. WARCParser and WACZParser unpack web archives and parse each captured response as an embedded document, and HttpParser handles a single raw HTTP response, which is useful for crawler output. ChmParser reads compiled HTML help. The 3.3.2 formats page does not mention the web archive parsers; the 4.1.x page does. Whether a feed or an archive should be parsed at all is a product decision: a WARC of a crawled site can contain thousands of embedded documents.

Audio, image and video

These families are metadata first.

  • Audio. AudioParser and MidiParser use javax.sound for simple formats; Mp3Parser, MP4Parser and the Ogg family (VorbisParser, OpusParser, SpeexParser, FlacParser) add sampling rate, channels, artist, title and lyrics where present. Speech-to-text is not in the standard set: it is AmazonTranscribe in tika-transcribe-aws (tika-parsers-ml) and needs AWS credentials.

  • Image. ImageParser uses javax.imageio for PNG, GIF, BMP and similar; JpegParser, TiffParser and RawTiffParser use the metadata-extractor library for Exif, IPTC and XMP; HeifParser (HEIF, HEIC, AVIF), JXLParser, WebPParser, PSDParser, BPGParser and ICNSParser extract metadata from their formats. WMFParser and EMFParser extract text from Microsoft vector drawings, and EMFParser also exposes embedded resources. The Bookshelf book-cover.jpg returned about twenty img: and tiff: keys.

  • Video. FLVParser, MP4Parser (MP4, QuickTime, 3GPP) and OggParser or TheoraParser extract limited metadata. Frame extraction, transcoding and probing go through ffmpeg via the external parser when it is installed, which is part of the -full Docker image and a configuration topic.

None of these read text from pixels; see OCR, vision models and natural language processing.

Java class files and source code

ClassParser (ASM) extracts class names and method signatures from .class files (verified on a compiled class in the tour), and PackageParser treats a jar as an archive. SourceCodeParser produces a formatted rendering of Java, C, C++ and Groovy source with simple metadata. Source files are the clearest example of the file-name hint: they are plain text to the magic detector and become text/x-java-source only through the name.

Mail formats

RFC822Parser (single .eml messages and message/x-emlx), MboxParser, OutlookPSTParser (with PSTMailItemParser for the items), TNEFParser (winmail.dat) and, for single Outlook .msg files, OfficeParser cover the mail formats. The message body is the text, the headers become metadata (message:from, message:to, dc:title for the subject, dcterms:created) and each attachment is an embedded document. The tour confirmed the .eml and the mbox (archive.mbox reported two embedded documents, one per message). PST stores can be very large and are the typical case for the process isolation of Tika Pipes and forked parsing; the worked publisher-email.eml walkthrough is in Embedded Documents & Recursive Parsing.

CAD, fonts, publishing and localisation

DWGParser, DGN8Parser and PRTParser extract metadata from AutoCAD, MicroStation and Cadkey files. TrueTypeParser and AdobeFontMetricParser extract simple font metadata. The publishing group is IDMLParser (InDesign IDML), MIFParser (FrameMaker), HwpV5Parser (Hangul Word Processor) and the localisation interchange parsers XLIFF12Parser, XLZParser and TMXParser. These are specialist formats: rely on them only after testing with your own files.

Scientific, executable and crypto formats

In the standard set DIFParser, MatParser (MATLAB .mat) and GeoGebraParser extract attribute metadata; the extended tika-parser-scientific-package adds GDAL, ISO 19139, GRIB, HDF, ISA-Tab and NetCDF and is not in tika-app. ExecutableParser reports platform, architecture and type for Windows PE, ELF and the many Mach-O variants, and UniversalExecutableParser unpacks macOS universal binaries. Pkcs7Parser parses the content of PKCS7 signed messages and TSDParser reads Time Stamped Data envelopes. The official page points to the detector configuration for finer CMS detection (the pkcs-7-detector, shown in Media Types & Detection).

Executables and archives are exactly the kinds of file an upload endpoint should reject or quarantine rather than parse; being supported is not the same as being safe to accept.

Databases

JackcessParser extracts metadata and tabular content from Microsoft Access, DBFParser reads dBase, FoxBASE, FoxPro and ESRI Shapefile .dbf files before version 7, and SAS7BDATParser reads SAS datasets. SQLite3Parser is in the extended package tika-parser-sqlite3-package because of its native sqlite-jdbc dependency; the first program on this page showed what happens without it (the file is identified as application/x-sqlite3 and parsed by EmptyParser).

OCR, vision models and natural language processing

The image parsers do not read text out of pixels. Three mechanisms do:

  • TesseractOCRParser (in the standard tika-parser-ocr-module) runs the tesseract binary when it is installed. It needs no configuration: with the binary on the PATH it OCRs images and scanned pages by default (see OCR with Tesseract). The Docker image apache/tika:4.1.0-full includes Tesseract, ImageMagick, ffmpeg and fonts; the minimal image does not.

  • Tess4J, the in-process Tesseract binding, in tika-parsers-ml (opt-in).

  • The VLM parsers for Claude, Gemini and OpenAI, for documents that OCR reads poorly (opt-in). They read credentials from the environment, never from the page or the repository, and they send your document to an external service, so they are also a data-protection decision.

The tika-parser-nlp-package adds NamedEntityParser (OpenNLP, Stanford CoreNLP, MITIE, NLTK or regex), JournalParser (Grobid), CTAKESParser (Apache cTAKES) and GeoParser, which enrich the metadata of other parsers and need models, training data or a service. Language identification is separate and is described in Language Detection & Translation.

Why does this matter for the Bookshelf scanned-loan-form.pdf and renamed-invoice.png? A PDF that contains only a page image has no text layer, so without an OCR engine it parses without error and produces no text. The metadata does say that OCR was needed: pdf:chars-per-page is 0 for the scanned page and pdf:ocr-page-count counts the pages that tripped the OCR verdict even when no engine ran (see PDF Parsing). An intake service should route on those keys, or count a file with empty text as empty rather than successful, and send it to an OCR-enabled pipeline.

Source: Supported Document Formats, Tika 4.1.x docs and Tesseract OCR parser, Tika 4.1.x docs. The OCR engine options are on OCR with Tesseract.

Excluding and restricting parsers

The standard set includes parsers that open archives, executables and mail stores. A service that only needs documents can remove what it does not want. In 4.x this is a tika-config.json, loaded with TikaLoader, and the parser keys are the friendly names printed by --list-parser-names:

{
  "parsers": [
    {
      "default-parser": {
        "exclude": ["pdf-parser", "rar-parser"]
      }
    }
  ]
}

The next program loads the default and the restricted configuration and asks both whether a parser exists for the type of each Bookshelf sample. It is a guard that an intake service can run before parsing, so that "no parser" is an explicit decision instead of an empty result.

import java.io.IOException;
import java.nio.file.Path;
import org.apache.tika.config.loader.TikaLoader;
import org.apache.tika.detect.Detector;
import org.apache.tika.io.TikaInputStream;
import org.apache.tika.metadata.Metadata;
import org.apache.tika.mime.MediaType;
import org.apache.tika.parser.ParseContext;
import org.apache.tika.parser.Parser;

public class SupportGuard {

    static MediaType detect(Detector detector, Path file) throws IOException {
        Metadata metadata = new Metadata();
        try (TikaInputStream in = TikaInputStream.get(file, metadata)) {
            return detector.detect(in, metadata, new ParseContext());
        }
    }

    static boolean hasParser(Parser parser, MediaType type) {
        return parser.getSupportedTypes(new ParseContext()).contains(type.getBaseType());
    }

    public static void main(String[] args) throws Exception {
        TikaLoader standard = TikaLoader.loadDefault();
        TikaLoader noPdf = TikaLoader.load(Path.of("tika-config-no-pdf.json"));
        Detector detector = standard.loadDetectors();
        Parser standardParser = standard.loadAutoDetectParser();
        Parser noPdfParser = noPdf.loadAutoDetectParser();

        for (String name : new String[] {"manuscript.docx", "catalogue.pdf", "novel.epub", "publisher-email.eml"}) {
            MediaType type = detect(detector, Path.of("files", name));
            System.out.printf("%-20s %-72s standard=%-5s no-pdf=%s%n", name, type,
                    hasParser(standardParser, type), hasParser(noPdfParser, type));
        }
        System.out.println("supported types: standard=" + standardParser.getSupportedTypes(new ParseContext()).size()
                + " no-pdf=" + noPdfParser.getSupportedTypes(new ParseContext()).size());
    }
}

Output:

manuscript.docx      application/vnd.openxmlformats-officedocument.wordprocessingml.document  standard=true  no-pdf=true
catalogue.pdf        application/pdf                                                          standard=true  no-pdf=false
novel.epub           application/epub+zip                                                     standard=true  no-pdf=true
publisher-email.eml  message/rfc822                                                           standard=true  no-pdf=true
supported types: standard=258 no-pdf=256

Excluding pdf-parser and rar-parser removed two supported types (258 to 256), and catalogue.pdf no longer has a parser. In a 3.x project the equivalent is the <parsers> section of tika-config.xml, which TikaConfig loads. Restricting the parsers is a layer of defence, not a sandbox: crashes and runaway memory in the parsers that remain are still the caller’s problem unless they run in a forked process, as the security model on the Tika site explains.

Source: Using Tika as a Library (Java API) and TikaLoader, Javadoc 4.1.0.

The detection and parsing path as one picture

flowchart LR file["Uploaded file"] --> detect["Detectors: magic, name, container"] detect --> type["Media type"] type --> lookup{"Parser registered for this type?"} lookup -->|"yes"| family["Family parser: PDFBox, POI, jsoup, Commons Compress ..."] lookup -->|"no"| empty["EmptyParser: metadata only"] family --> out["XHTML events and Metadata"] family -->|"container formats"| emb["Embedded documents, parsed again"] emb --> detect out --> check{"Text empty?"} empty --> check check -->|"yes"| ocr["Route to OCR pipeline or reject"] check -->|"no"| index["Index and store"]

The loop from the embedded documents back to detection is why a single upload can exercise many families: a .eml runs RFC822Parser, then detects catalogue.pdf and runs PDFParser, which may in turn detect and parse an embedded image.

Choosing between families: practical guidance for Bookshelf

Bookshelf input Decision

manuscript.docx, catalogue.pdf

Both are in the standard set. Parse them in a forked process, because POI and PDFBox are the parsers most often fed hostile files.

scanned-loan-form.pdf, renamed-invoice.png

Parse succeeds, text is empty. Detect by content (the png is really a PDF), then route empty-text results to OCR.

book-cover.jpg

Metadata only (dimensions, Exif if present). Store the metadata, not a text field.

publisher-email.eml and samples.zip

Containers: decide the maximum depth and count before parsing, and index the children as separate documents.

novel.epub

Text and Dublin Core metadata. Use the metadata for the title and author fields.

reviews-es.html, reseñas-fr.txt, legacy-catalogue.txt

Text: the interesting work is the charset and the language, in Character Encoding Detection and Language Detection & Translation.

A SQLite file, a WebM video, an executable

Detected, but EmptyParser or metadata only. Reject by policy at the edge.

What changed from the book to 4.x

Topic Tika 1.x (Tika in Action, chapter 8) Tika 4.x (4.1.0 measured)

Parser selection

ServiceLoader discovery of Parser classes, wired through CompositeParser

Same SPI, plus JSON configuration (TikaLoader, default-parser with exclude) and friendly component names such as pdf-parser

HTML

A TagSoup-based parser

JSoupParser

Packaging

One tika-parsers artifact

tika-parsers-standard-package made of tika-parser-*-module artifacts, plus extended and ml groups

Mail, web and image families

Messages, mbox, JPEG and a few image formats

Adds PST, winmail.dat, WARC and WACZ, HEIF, JPEG XL and many metadata-only formats (per the 4.1.x page)

Scientific formats

HDF, NetCDF and others in the main parser set

Split out to tika-parsers-extended (GDAL, GRIB, HDF, ISA-Tab, NetCDF) because of native dependencies

OCR

Not covered

Tesseract when its binary is installed; Tess4J and VLM parsers opt-in

Listing parsers

Code against CompositeParser

DefaultParser.getAllComponentParsers(), --list-parser-details, /parsers/details

The 3.x formats page (3.3.2) and the 4.1.x page differ in wording and in the formats named: the newer page lists the web archive, HEIF and JPEG XL, iWork 2013/2018, Markdown and flat OpenDocument parsers, Brotli, LZ4 and Snappy, and the in-process OCR and VLM options, none of which the 3.3.2 page mentions. That is a statement about the two pages, not a guarantee that the corresponding classes did not exist in 3.x; check the 3.x class list with --list-parsers on a 3.x distribution before assuming a format is unavailable there.

Pitfalls

  • Treating "no exception" as "parsed". Check the media type, tk:parsed-by and the content length. EmptyParser succeeds silently.

  • Trusting a format table over the class path. The parsers that exist at run time are those on the class path; a slim or hand-built dependency set can lack a family (for example SQLite, GDAL, or the whole PDF module). Ask DefaultParser or /parsers/details.

  • Missing external tools. Tesseract and ffmpeg parsers advertise no types without the binary. The -full Docker tag includes them, the minimal tag does not.

  • Forgetting the name hint. Source code and small CSV files depend on TikaInputStream.get(path, metadata).

  • Expecting layout. Tables, columns, headers and footers, and reading order are best-effort, and for PDF a text layer is a prerequisite.

  • Assuming extended parsers ship with the server. The official page states that SQLite3 and the scientific parsers are not in tika-app; add the package, or build an image that has it.

  • Parsing everything that is supported. Supported is not safe. Archives, executables and web archives can expand enormously and should be limited or rejected at the edge.

  • Quoting counts. 89 parsers, 258 media types and roughly 1,700 known types are measurements of 4.1.0 on one class path, not constants of the API.

What this page does not provide

  • No claim of format coverage beyond the 4.1.x formats page and the measured class path; the response layout of the /parsers endpoints was not observed because no server was started for this page.

  • No per-format accuracy or throughput numbers. The sample files are tiny and generated, so the output shows what a parser does, not how well it does it on real documents.

  • The OCR page of the 4.1.x documentation, the Tess4J, VLM and NLP packages were listed from the official formats page and the POMs but not run.

  • Nothing is said about the formats that only the -full image or an external tool can handle beyond what the official pages state.

References