Metadata Filters
A metadata filter rewrites the metadata after parsing and before the result is emitted or serialized — the last chance to drop a field, rename it, normalize it, or add a derived one. Filters are the supported way to shape Tika’s output; parsers are not the place to do it.
Filters run in tika-app, tika-server and Tika Pipes alike, on the whole metadata list
(container document first, then each embedded document).
The metadata-filters section
metadata-filters is a top-level array. The filters run in the order listed, each one seeing what
the previous one produced.
{
"metadata-filters": [
{ "include-field-metadata-filter": { "include": ["tk:content", "Content-Type"] } },
"date-normalizing-metadata-filter"
]
}
An element is either a string (the filter’s name, default settings) or an object keyed by that name with its configuration.
There is no default-metadata-filter and no implicit filtering. If you omit the section
— or give it an empty array — no filter runs and the metadata is emitted unchanged. This is
unlike parsers and detectors, where a default-parser / default-detector entry restores the
components you did not name.
|
Built-in filters
These ship in tika-core and need no extra dependency.
| Name | What it does | Options (default) |
|---|---|---|
|
Keeps only the named fields; drops everything else. |
|
|
Drops the named fields; keeps everything else. |
|
|
Renames fields. With |
|
|
Removes a document’s entire |
|
|
Empties (but keeps) the |
|
|
Rewrites every |
|
|
Runs a regex against the first value of |
|
|
If both latitude and longitude are present, writes |
|
|
Rewrites 4.x |
|
|
Does nothing. Only useful as an explicit "filter nothing here". |
none |
Filters from optional modules
Adding the module to the classpath is enough to make the name resolvable.
| Name | Module | What it adds |
|---|---|---|
|
|
Chunks |
|
|
Detects the language of the extracted text and writes it to the metadata. See Language Detection. |
|
|
Scores extraction quality per document: |
Common tasks
Emit only the fields your index needs
{
"metadata-filters": [
{
"include-field-metadata-filter": {
"include": ["tk:content", "Content-Type", "dc:title", "dc:creator"]
}
}
]
}
Rename fields for a downstream schema
excludeUnmapped defaults to true, so this keeps only the four mapped fields, under their new
names:
{
"metadata-filters": [
{
"field-name-mapping-filter": {
"excludeUnmapped": true,
"mappings": {
"tk:content": "content",
"Content-Type": "mime",
"dc:title": "title",
"dc:creator": "author"
}
}
}
]
}
Strip the parameters off a media type
Content-Type often arrives as text/plain; charset=UTF-8. To index the base type only:
{
"metadata-filters": [
{
"capture-group-metadata-filter": {
"sourceField": "Content-Type",
"targetField": "Content-Type",
"regex": "\\A([^;]+)"
}
}
]
}
Drop the metadata of embedded images
{
"metadata-filters": [
{ "clear-by-attachment-type-metadata-filter": { "types": ["INLINE"] } }
]
}
To remove those documents from the list altogether rather than blank them, filter by media type instead:
{
"metadata-filters": [
{ "remove-by-mime-metadata-filter": { "mimes": ["image/jpeg", "image/png"] } }
]
}
Ordering
Composition is literal: filter n sees filter n-1's output. Two consequences worth planning around.
-
An allow-list runs last, or it removes the fields a later filter wanted.
include-field-metadata-filterbeforegeo-point-metadata-filterdrops the latitude and longitude the geo filter reads — unless you included them. -
A rename runs last, or later filters have to be configured against the new names.
Where filters do and do not apply
-
tika-appapplies them to the metadata list before writing output. -
tika-server’s `/tika,/rmeta,/metaand/unpackparse in forked JVMs, and the filters configured in the server’stika-config.jsonare applied there before the response is written. -
Tika Pipes applies them at the emit edge, before the emitter runs.
parse-context can carry a per-request metadata-filters list, which replaces the configured
one for that request rather than adding to it.
In CONTENT_ONLY parse mode, Tika applies an
include-field-metadata-filter for tk:content and tk:exception:container-exception when you have
configured no filter of your own. Configure one and yours wins — including having to keep
tk:content yourself.
|
Writing your own
MetadataFilter is an extension point. Extend MetadataFilterBase if one Metadata at a time is
enough, or MetadataFilter if you need the whole list; annotate with @TikaComponent to get a
config name. Writing a reserved tk: key by name (rather than through its Property) requires
Metadata#setTrusted / addTrusted. See
Serialization and Configuration for a worked example.
Source
-
org.apache.tika.metadata.filter— the built-in filters -
CompositeMetadataFilter— the ordering semantics above