Getting Started with the Java API

Consider a service first

For most use cases, run Tika as a separate service rather than embedding it: tika-server (REST) or tika-grpc. A parser crash then cannot affect your application, you deploy from the official Docker images, you can call it from any language, and you upgrade Tika independently of your own release cycle.

Embed the Java API when you need tight integration with Tika internals, cannot run a network service, or have customization requirements a service cannot express.

PipesForkParser

If you do embed Tika, use PipesForkParser from tika-pipes-fork-parser. It parses in a separate JVM — process isolation, automatic restart after a crash, configurable timeouts — and is thread-safe, so one instance serves many threads.

<dependency>
    <groupId>org.apache.tika</groupId>
    <artifactId>tika-pipes-fork-parser</artifactId>
    <version>4.0.0</version>
</dependency>
import java.nio.file.Path;
import org.apache.tika.pipes.fork.PipesForkParser;
import org.apache.tika.pipes.fork.PipesForkResult;

Path file = Path.of("/path/to/document.pdf");

try (PipesForkParser parser = new PipesForkParser()) {
    PipesForkResult result = parser.parse(file);

    if (result.isSuccess()) {
        String content = result.getContent();
        // process content...
    } else {
        // handle failure
    }
}

See PipesForkParserExample.java in the tika-example module for embedded documents, custom configuration, error handling and batch processing.

Without process isolation

Calling parsers directly — AutoDetectParser and friends — on untrusted content can cause OutOfMemoryErrors, infinite loops, and crashes that take down your whole application. Never run Tika in the same JVM as critical infrastructure.

If you go that route, your application owns the isolation: Tika cannot enforce a parse timeout, a memory limit, a process kill, or a crash recovery without a separate process. Read The Robustness of Apache Tika and the Apache Tika Security Model first.