Why does txtfetch say "1,683 detected" but only "615 parsed"?

Apache Tika's detector recognizes a media type from its bytes. It looks at magic numbers, container structure, or XML namespaces. This works independently of whether any parser can read that type's content. Detection just means Tika can NAME the file correctly; parsing means it can hand back text or metadata. tika-server-standard 3.3.1 detects 1,683 media types. It has a real parser, direct or via supertype fallback, behind 615 of them. The other 1,068 come back correctly typed and empty.

What happens if I send a detect-only file to the API?

You get the correctly identified content type and an extraction error, never a fabricated text dump and never metadata dressed up as extracted text. The lookup above says so explicitly for every detect-only type it knows about, including the exact media type Tika assigns it.

Why do some formats look supported on other pages but show up detect-only here?

Because this page checks the actual pinned build instead of assuming from the file extension. .wpd (plain WordPerfect, as opposed to its versioned variants), .mobi, and .jp2 all detect cleanly in tika-server-standard 3.3.1, but none has a parser behind it. .azw3 isn't a media type this Tika version recognizes at all. All four are called out honestly below instead of quietly staying on a "we handle this" list.

Does OCR change any of these verdicts?

For 6 raster image types (PNG, JPEG, GIF, BMP, TIFF, WebP), yes. The generator that built this data runs without Tesseract on PATH. It can only see Tika's fallback metadata-only image parsers. The Lambda has Tesseract installed. Tika prefers TesseractOCRParser for those exact types. In production, they get real OCR text, not just dimensions and EXIF tags. The lookup and the table both flag this wherever it applies.

How was this generated, and can I check it myself?

Dump.java (marketing/scripts/tika-coverage/) loads Tika's default config and walks every registered media type. It resolves each one to its concrete parser class. This follows Tika's own supertype fallback, the same lookup CompositeParser itself does. Because of that, a type like text/x-python correctly shows up parsed via TextAndCSVParser instead of falsely reading as unsupported. build-coverage.mjs downloads tika-server-standard 3.3.1 and the Corretto JDK pinned in terraform/lambda-layers/build/versions.env. It verifies both against the checksums pinned there. Then it runs the dump and writes the JSON this page reads. See docs/tika-coverage.md for the exact commands.

Why is this data committed instead of generated on every build?

Regenerating it needs a ~75MB jar and a JDK on the build machine. That's reasonable to run by hand when the Tika version bumps, not something to add to every CI run. Instead, a test asserts the committed data's tikaVersion matches versions.env, so a layer bump that isn't accompanied by regenerating this file fails the build.

1,683 media types is a lot of table rows. Why not one page per format?

That's a doorway-page pattern: hundreds of thin, templated pages targeting long-tail keywords. It would drag the whole domain's quality signal down. A single well-organized reference page can capture the same traffic just as well. This page is deliberately one deep resource with a real lookup tool, not 1,683 near-duplicates.

Every format, checked.

“1,000+ formats” is true, and also not the number that matters. Here's what tika-server-standard actually parses, measured against the exact jar this build ships, not assumed from a list.

the-measurement

1,683media types detected

615have a real parser (217 direct + 398 via supertype fallback)

601file extensions reach a parser

80distinct parser classes doing the work

Detection and parsing are different claims. Tika's detector reads a file's magic bytes, container structure, or XML namespace, and names the media type correctly. That's the 1,000+ figure everyone, us included, quotes elsewhere on this site. Parsing is a separate question: does any registered parser actually turn that type into text or metadata? For tika-server-standard 3.3.1, the honest answer is 615 of the 1,683 types it detects. The rest come back correctly named and empty.

Provenance: Tika version 3.3.1, jar SHA-256 755d252de43a1995151db3a25c825332d2f27371272c41459bb5b78e21b028bd. This is the exact jar pinned in terraform/lambda-layers/build/versions.env and shipped in the extraction Lambda's layer. Re-run it yourself: download that jar, verify the checksum, then run marketing/scripts/tika-coverage/build-coverage.mjs. The repo's docs/tika-coverage.md has the exact commands. No API key or account needed; it's a standalone Java program against a public jar. Generated 2026-08-13.

look-it-up

Type a file extension (.wpd) or a media type (image/png). Get the verdict this exact build gives it: parsed and by which parser, detect-only, or unknown to Tika entirely.

parsed

Every one of the 601 file extensions that reach a real parser in this build, A to Z. Static markup: this table is here with JavaScript off. It's what a search crawler or an LLM reading llms-full.txt sees too.

Extension	Media type	Parser	What you get
`.3dml`	text/vnd.in3d.3dml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.3g2`	video/3gpp2	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.3gp`	video/3gpp	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.3mf`	application/vnd.ms-package.3dmanufacturing-3dmodel+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.4th`	text/x-forth	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.7z`	application/x-7z-compressed	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.a`	application/x-archive	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.aart`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ac`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.accdb`	application/x-msaccess	JackcessParser	table and row data from a Microsoft Access database file, as text.
`.acfm`	application/x-font-adobe-metric	AdobeFontMetricParser	the font's metadata (name, glyph widths) — a font file has no prose to extract.
`.ad`	text/x-asciidoc	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ada`	text/x-ada	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.adb`	text/x-ada	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.adoc`	text/x-asciidoc	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ads`	text/x-ada	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.afm`	application/x-font-adobe-metric	AdobeFontMetricParser	the font's metadata (name, glyph widths) — a font file has no prose to extract.
`.ai`	application/illustrator	PDFParser	the text layer, reading order reconstructed across columns and pages — if the PDF is a scan with no text layer, this parser returns nothing and Tesseract OCR fills in behind it.
`.aif`	audio/x-aiff	AudioParser	container-level metadata (sample rate, channels, duration) for uncompressed/basic audio formats — never a transcript.
`.aifc`	audio/x-aiff	AudioParser	container-level metadata (sample rate, channels, duration) for uncompressed/basic audio formats — never a transcript.
`.aiff`	audio/x-aiff	AudioParser	container-level metadata (sample rate, channels, duration) for uncompressed/basic audio formats — never a transcript.
`.air`	application/vnd.adobe.air-application-installer-package+zip	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.aj`	text/x-aspectj	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.al`	text/x-perl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.am`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.amf`	application/x-amf	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.amfm`	application/x-font-adobe-metric	AdobeFontMetricParser	the font's metadata (name, glyph widths) — a font file has no prose to extract.
`.anpa`	text/vnd.iptc.anpa	IptcAnpaParser	the article body text from this news-wire transmission format.
`.apk`	application/vnd.android.package-archive	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.applescript`	text/x-applescript	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.apt`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ar`	application/x-archive	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.arc`	application/x-internet-archive	WARCParser	each captured HTTP response unpacked and re-run through detection — a page crawled into a WARC comes back as that page's extracted text.
`.arj`	application/x-arj	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.as`	text/x-actionscript	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.asciidoc`	text/x-asciidoc	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.asice`	application/vnd.etsi.asic-e+zip	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.asics`	application/vnd.etsi.asic-s+zip	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.asm`	text/x-assembly	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.asp`	text/asp	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.aspx`	text/aspdotnet	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.asx`	application/x-ms-asx	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.atom`	application/atom+xml	FeedParser	every entry's title, summary, and body text pulled out of the feed, not just the feed's own metadata.
`.atomcat`	application/atomcat+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.atomsvc`	application/atomsvc+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.au`	audio/basic	AudioParser	container-level metadata (sample rate, channels, duration) for uncompressed/basic audio formats — never a transcript.
`.awk`	text/x-awk	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.bas`	text/x-basic	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.bash`	application/x-sh	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.bat`	application/x-bat	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.bau`	application/vnd.openofficeorg.autotext	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.bib`	application/x-bibtex-text-file	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.bibtex`	application/x-bibtex-text-file	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.bmp`	image/bmp	ImageParser +OCR	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.boz`	application/x-bzip2	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.bpg`	image/x-bpg	BPGParser	container metadata from this rare image format — not OCR.
`.bpm`	application/bizagi-modeler	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.br`	application/x-brotli	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.brotli`	application/x-brotli	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.bsh`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.bz`	application/x-bzip	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.bz2`	application/x-bzip2	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.c`	text/x-c++src	SourceCodeParser	the raw source as text, same as TextAndCSVParser, plus language-aware metadata for a handful of C-family languages.
`.cbl`	text/x-cobol	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cc`	text/x-c++src	SourceCodeParser	the raw source as text, same as TextAndCSVParser, plus language-aware metadata for a handful of C-family languages.
`.ccxml`	application/ccxml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.cdxml`	application/vnd.chemdraw+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.cfc`	text/x-coldfusion	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cfg`	text/x-config	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cfm`	text/x-coldfusion	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cfml`	text/x-coldfusion	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cgi`	text/x-cgi	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.chm`	application/vnd.ms-htmlhelp	ChmParser	the text of every HTML page bundled inside the .chm help file.
`.cl`	text/x-common-lisp	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.class`	application/java-vm	ClassParser	structural metadata about the compiled class (version, source file name) — never source code, because a .class file doesn't contain any.
`.classpath`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.clj`	text/x-clojure	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cls`	text/x-vbasic	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cmd`	application/x-bat	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cnd`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cob`	text/x-cobol	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.coffee`	text/x-coffeescript	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.com`	application/x-msdownload	ExecutableParser	structural metadata about the binary — architecture, linked libraries, sections — never readable prose, because compiled binaries don't contain any.
`.conf`	text/x-config	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.config`	text/x-config	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cpio`	application/x-cpio	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.cpp`	text/x-c++src	SourceCodeParser	the raw source as text, same as TextAndCSVParser, plus language-aware metadata for a handful of C-family languages.
`.cr2`	image/x-canon-cr2	TiffParser	dimensions and embedded EXIF tags — no OCR from this parser alone (TIFF gets real OCR in production; see the Tesseract note below).
`.cr3`	image/x-canon-cr3	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.cs`	text/x-csharp	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.css`	text/css	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.csv`	text/csv	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.curl`	text/vnd.curl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cwiki`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.cxx`	text/x-c++src	SourceCodeParser	the raw source as text, same as TextAndCSVParser, plus language-aware metadata for a handful of C-family languages.
`.d`	text/x-d	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.data`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.davmount`	application/davmount+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.dbase`	application/x-dbf	DBFParser	every record's field values, as text — a flat-file database format still used by some GIS and legacy business tools.
`.dbase3`	application/x-dbf	DBFParser	every record's field values, as text — a flat-file database format still used by some GIS and legacy business tools.
`.dbf`	application/x-dbf	DBFParser	every record's field values, as text — a flat-file database format still used by some GIS and legacy business tools.
`.dcl`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.dcurl`	text/vnd.curl.dcurl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.dd2`	application/vnd.oma.dd2+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.deb`	application/x-debian-package	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.def`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.dib`	image/bmp	ImageParser +OCR	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.dif`	application/dif+xml	DIFParser	cell values from this old spreadsheet interchange format, as text.
`.diff`	text/x-diff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.dita`	application/dita+xml; format=topic	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.ditamap`	application/dita+xml; format=map	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.ditaval`	application/dita+xml; format=val	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.dll`	application/x-msdownload	ExecutableParser	structural metadata about the binary — architecture, linked libraries, sections — never readable prose, because compiled binaries don't contain any.
`.doc`	application/msword	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.docm`	application/vnd.ms-word.document.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.docx`	application/vnd.openxmlformats-officedocument.wordprocessingml.document	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.dot`	application/msword	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.dotm`	application/vnd.ms-word.template.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.dotx`	application/vnd.openxmlformats-officedocument.wordprocessingml.template	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.dpr`	text/x-pascal	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.drc`	video/x-dirac	OggParser	the container's tag metadata (title, artist, encoder) — never a transcript of what's actually said or played.
`.dsc`	text/prs.lines.tag	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.dsp`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.dsw`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.dtb`	application/x-dtbook+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.dtd`	application/xml-dtd	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.dwfx`	model/vnd.dwfx+xps	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.dwg`	image/vnd.dwg	DWGParser	header and structural metadata from a .dwg drawing — not the drawn content as text.
`.e`	text/x-eiffel	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ear`	application/x-tika-java-enterprise-archive	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.egrm`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.el`	text/x-emacs-lisp	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.emf`	image/emf	EMFParser	header metadata from this vector graphics format — not OCR; EMF is drawing commands, not a photographed page.
`.eml`	message/rfc822	RFC822Parser	headers (from/to/subject/date) plus the message body, with attachments recursed and extracted the same as an archive member.
`.emlx`	message/x-emlx	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.emma`	application/emma+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.emz`	image/x-emf-compressed	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.ent`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.epub`	application/epub+zip	EpubParser	the book's text, walked in spine order across every chapter file inside the container.
`.erl`	text/x-erlang	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.es3`	application/vnd.eszigno3+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.et3`	application/vnd.eszigno3+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.etx`	text/x-setext	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.exe`	application/x-dosexec	ExecutableParser	structural metadata about the binary — architecture, linked libraries, sections — never readable prose, because compiled binaries don't contain any.
`.exp`	text/x-expect	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.f`	text/x-fortran	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.f77`	text/x-fortran	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.f90`	text/x-fortran	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.fb2`	application/x-fictionbook+xml	FictionBookParser	the book's text from this Russian-originated XML ebook format's body.
`.flac`	audio/x-flac	FlacParser	the file's Vorbis-comment tags (title, artist, album) — never a transcript of the audio itself.
`.flv`	video/x-flv	FLVParser	container-level metadata (duration, codec) — never a transcript.
`.flx`	text/vnd.fmi.flexstor	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.fly`	text/vnd.fly	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.fn`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.fo`	application/xslfo+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.fodp`	application/vnd.oasis.opendocument.flat.presentation	FlatOpenDocumentParser	the same document body text as OpenDocumentParser, for ODF's single-XML-file variant (.fodt/.fods/.fodp) instead of the zipped one.
`.fods`	application/vnd.oasis.opendocument.flat.spreadsheet	FlatOpenDocumentParser	the same document body text as OpenDocumentParser, for ODF's single-XML-file variant (.fodt/.fods/.fodp) instead of the zipped one.
`.fodt`	application/vnd.oasis.opendocument.flat.text	FlatOpenDocumentParser	the same document body text as OpenDocumentParser, for ODF's single-XML-file variant (.fodt/.fods/.fodp) instead of the zipped one.
`.for`	text/x-fortran	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.frm`	text/x-vbasic	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ft`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.fv`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.g`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.gif`	image/gif	ImageParser +OCR	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.go`	text/x-go	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.grm`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.groovy`	text/x-groovy	SourceCodeParser	the raw source as text, same as TextAndCSVParser, plus language-aware metadata for a handful of C-family languages.
`.grxml`	application/srgs+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.gtar`	application/x-gtar	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.gv`	text/vnd.graphviz	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.gz`	application/gzip	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.h`	text/x-c++hdr	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.haml`	text/x-haml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.handlers`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.heic`	image/heic	HeifParser	container and EXIF metadata from Apple's modern photo format — no OCR from this parser alone.
`.heif`	image/heif	HeifParser	container and EXIF metadata from Apple's modern photo format — no OCR from this parser alone.
`.hh`	text/x-c++hdr	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.hp`	text/x-c++hdr	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.hpp`	text/x-c++hdr	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.hs`	text/x-haskell	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.htc`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.htm`	text/html	JSoupParser	the visible page text with boilerplate (nav, scripts, styles) stripped, the same reader behind /tools/html-to-text.
`.html`	text/html	JSoupParser	the visible page text with boilerplate (nav, scripts, styles) stripped, the same reader behind /tools/html-to-text.
`.hwpx`	application/hwp+zip	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.hx`	text/x-haxe	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.hxx`	text/x-c++hdr	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.i3`	text/x-modula	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ibooks`	application/x-ibooks+zip	EpubParser	the book's text, walked in spine order across every chapter file inside the container.
`.icns`	image/icns	ICNSParser	the icon container's embedded image list metadata — not OCR.
`.ico`	image/vnd.microsoft.icon	ImageParser	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.ics`	text/calendar	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.idl`	text/x-idl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.idml`	application/vnd.adobe.indesign-idml-package	IDMLParser	story and text-frame content pulled from an InDesign package's XML story files.
`.ifb`	text/calendar	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ig`	text/x-modula	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ihtml`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.in`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ini`	text/x-ini	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.inx`	application/x-adobe-indesign-interchange	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.ipa`	application/x-itunes-ipa	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.irp`	application/vnd.irepository.package+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.iso19139`	text/iso19139+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.itk`	text/x-tcl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.jad`	text/vnd.sun.j2me.app-descriptor	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.jar`	application/java-archive	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.java`	text/x-java-source	SourceCodeParser	the raw source as text, same as TextAndCSVParser, plus language-aware metadata for a handful of C-family languages.
`.jb2`	image/x-jbig2	ImageParser	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.jbig2`	image/x-jbig2	ImageParser	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.jfi`	image/jpeg	JpegParser +OCR	EXIF tags (camera, GPS, capture date) — no OCR from this parser alone (JPEG gets real OCR in production; see the Tesseract note below).
`.jfif`	image/jpeg	JpegParser +OCR	EXIF tags (camera, GPS, capture date) — no OCR from this parser alone (JPEG gets real OCR in production; see the Tesseract note below).
`.jif`	image/jpeg	JpegParser +OCR	EXIF tags (camera, GPS, capture date) — no OCR from this parser alone (JPEG gets real OCR in production; see the Tesseract note below).
`.jl`	text/x-common-lisp	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.jmx`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.jnilib`	application/x-java-jnilib	UniversalExecutableParser	structural metadata about the binary (architecture, linked libraries) — never readable prose.
`.jpe`	image/jpeg	JpegParser +OCR	EXIF tags (camera, GPS, capture date) — no OCR from this parser alone (JPEG gets real OCR in production; see the Tesseract note below).
`.jpeg`	image/jpeg	JpegParser +OCR	EXIF tags (camera, GPS, capture date) — no OCR from this parser alone (JPEG gets real OCR in production; see the Tesseract note below).
`.jpg`	image/jpeg	JpegParser +OCR	EXIF tags (camera, GPS, capture date) — no OCR from this parser alone (JPEG gets real OCR in production; see the Tesseract note below).
`.js`	text/javascript	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.json`	application/json	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.jsp`	text/x-jsp	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.junit`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.jx`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.jxl`	image/jxl	JXLParser	embedded metadata from this newer JPEG successor format — not OCR.
`.kar`	audio/midi	MidiParser	track and instrument metadata from a MIDI file — MIDI encodes notes, not sound or speech, so there's nothing to transcribe.
`.key`	application/vnd.apple.keynote	IWorkPackageParser	the document body text from Pages/Numbers/Keynote's newer package format.
`.kml`	application/vnd.google-earth.kml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.kmz`	application/vnd.google-earth.kmz	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.l`	text/x-lex	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.latex`	application/x-latex	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.lbe`	application/vnd.llamagraphics.life-balance.exchange+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.less`	text/x-less	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.lhs`	text/x-haskell	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.link66`	application/vnd.route66.link66+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.lisp`	text/x-common-lisp	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.list`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.log`	text/x-log	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.lostxml`	application/lost+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.lsp`	text/x-common-lisp	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.lua`	text/x-lua	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.lyr`	application/x-esri-layer	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.lz4`	application/x-lz4	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.lzma`	application/x-lzma	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.m`	text/x-objcsrc	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.m2a`	audio/mpeg	Mp3Parser	ID3 tag metadata (title, artist, album) — never a transcript of the audio.
`.m3`	text/x-modula	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.m3a`	audio/mpeg	Mp3Parser	ID3 tag metadata (title, artist, album) — never a transcript of the audio.
`.m4`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.m4a`	audio/mp4	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.m4b`	audio/mp4	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.m4s`	video/iso.segment	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.m4v`	video/x-m4v	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.ma`	application/mathematica	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.man`	text/troff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.manifest`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.markdown`	text/markdown	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mat`	application/x-matlab-data	MatParser	variable names and array metadata from a .mat file — numeric data, not prose.
`.mathml`	application/mathml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.mb`	application/mathematica	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mbox`	application/mbox	MboxParser	every message in the mailbox file split out and parsed individually, headers and body both.
`.mcurl`	text/vnd.curl.mcurl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.md`	text/markdown	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mdb`	application/x-msaccess	JackcessParser	table and row data from a Microsoft Access database file, as text.
`.mdo`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mdtext`	text/markdown	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.me`	text/troff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.memgraph`	application/x-memgraph	PListParser	the key/value structure of an Apple binary property list, as text — used for a handful of Apple-adjacent formats, not general documents.
`.meta`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mf`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mg`	text/x-modula	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mht`	multipart/related	RFC822Parser	headers (from/to/subject/date) plus the message body, with attachments recursed and extracted the same as an archive member.
`.mhtml`	multipart/related	RFC822Parser	headers (from/to/subject/date) plus the message body, with attachments recursed and extracted the same as an archive member.
`.mid`	audio/midi	MidiParser	track and instrument metadata from a MIDI file — MIDI encodes notes, not sound or speech, so there's nothing to transcribe.
`.midi`	audio/midi	MidiParser	track and instrument metadata from a MIDI file — MIDI encodes notes, not sound or speech, so there's nothing to transcribe.
`.mif`	application/vnd.mif	MIFParser	the document body text from Adobe FrameMaker's plain-text interchange format.
`.mime`	message/rfc822	RFC822Parser	headers (from/to/subject/date) plus the message body, with attachments recursed and extracted the same as an archive member.
`.mjs`	text/javascript	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mkd`	text/markdown	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ml`	text/x-ml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mli`	text/x-ocaml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mmap`	application/vnd.mindjet.mindmanager	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.mmas`	application/vnd.mindjet.mindmanager	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.mmat`	application/vnd.mindjet.mindmanager	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.mmmp`	application/vnd.mindjet.mindmanager	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.mmp`	application/vnd.mindjet.mindmanager	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.mmpt`	application/vnd.mindjet.mindmanager	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.mov`	video/quicktime	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.mp2`	audio/mpeg	Mp3Parser	ID3 tag metadata (title, artist, album) — never a transcript of the audio.
`.mp2a`	audio/mpeg	Mp3Parser	ID3 tag metadata (title, artist, album) — never a transcript of the audio.
`.mp3`	audio/mpeg	Mp3Parser	ID3 tag metadata (title, artist, album) — never a transcript of the audio.
`.mp4`	video/mp4	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.mp4a`	audio/mp4	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.mp4s`	application/mp4	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.mp4v`	video/mp4	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.mpd`	application/dash+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.mpg4`	video/mp4	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.mpga`	audio/mpeg	Mp3Parser	ID3 tag metadata (title, artist, album) — never a transcript of the audio.
`.mpkg`	application/vnd.apple.installer+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.mpp`	application/vnd.ms-project	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.mpt`	application/vnd.ms-project	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.mpx`	application/x-project	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ms`	text/troff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.mscml`	application/mediaservercontrol+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.msg`	application/vnd.ms-outlook	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.msi`	application/x-ms-installer	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.msp`	application/x-ms-installer	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.mst`	application/x-ms-installer	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.musicxml`	application/vnd.recordare.musicxml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.mxml`	application/xv+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.n3`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.nar`	application/vnd.iptc.g2.newsmessage+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.nb`	application/mathematica	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ncx`	application/x-dtbncx+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.nroff`	text/troff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.numbers`	application/vnd.apple.numbers	IWorkPackageParser	the document body text from Pages/Numbers/Keynote's newer package format.
`.ocaml`	text/x-ocaml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.odc`	application/vnd.oasis.opendocument.chart	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.odf`	application/vnd.oasis.opendocument.formula	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.odft`	application/vnd.oasis.opendocument.formula-template	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.odg`	application/vnd.oasis.opendocument.graphics	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.odi`	application/vnd.oasis.opendocument.image	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.odp`	application/vnd.oasis.opendocument.presentation	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.ods`	application/vnd.oasis.opendocument.spreadsheet	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.odt`	application/vnd.oasis.opendocument.text	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.oga`	audio/ogg	OggParser	the container's tag metadata (title, artist, encoder) — never a transcript of what's actually said or played.
`.ogg`	audio/vorbis	VorbisParser	the codec's Vorbis-comment tags — never a transcript.
`.ogm`	video/x-ogm	OggParser	the container's tag metadata (title, artist, encoder) — never a transcript of what's actually said or played.
`.ogv`	video/ogg	OggParser	the container's tag metadata (title, artist, encoder) — never a transcript of what's actually said or played.
`.ogx`	application/ogg	OggParser	the container's tag metadata (title, artist, encoder) — never a transcript of what's actually said or played.
`.one`	application/onenote; format=one	OneNoteParser	text content from a OneNote section file — the Table of Contents and Package variants of OneNote's format are detect-only (no parser targets them yet).
`.opf`	application/oebps-package+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.opus`	audio/opus	OpusParser	the codec's Vorbis-comment-style tags — never a transcript.
`.osfpvg`	application/vnd.yamaha.openscoreformat.osfpvg+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.ost`	application/vnd.ms-outlook-pst	OutlookPSTParser	every message in the .pst/.ost mail store parsed individually — this is a whole mailbox, not a single email (see RFC822Parser/the email guide for a single .eml/.msg).
`.otc`	application/vnd.oasis.opendocument.chart-template	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.otg`	application/vnd.oasis.opendocument.graphics-template	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.oth`	application/vnd.oasis.opendocument.text-web	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.oti`	application/vnd.oasis.opendocument.image-template	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.otm`	application/vnd.oasis.opendocument.text-master	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.otp`	application/vnd.oasis.opendocument.presentation-template	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.ots`	application/vnd.oasis.opendocument.spreadsheet-template	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.ott`	application/vnd.oasis.opendocument.text-template	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.owl`	application/rdf+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.oxps`	application/vnd.ms-xpsdocument	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.oxt`	application/vnd.openofficeorg.extension	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.p`	text/x-pascal	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.p7c`	application/pkcs7-mime	Pkcs7Parser	the signed payload unwrapped and re-run through detection — the signature itself isn't extractable text.
`.p7m`	application/pkcs7-mime	Pkcs7Parser	the signed payload unwrapped and re-run through detection — the signature itself isn't extractable text.
`.p7s`	application/pkcs7-signature	Pkcs7Parser	the signed payload unwrapped and re-run through detection — the signature itself isn't extractable text.
`.pack`	application/x-java-pack200	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.pages`	application/vnd.apple.pages	IWorkPackageParser	the document body text from Pages/Numbers/Keynote's newer package format.
`.pas`	text/x-pascal	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.patch`	text/x-diff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.pdf`	application/pdf	PDFParser	the text layer, reading order reconstructed across columns and pages — if the PDF is a scan with no text layer, this parser returns nothing and Tesseract OCR fills in behind it.
`.pen`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.perl`	text/x-perl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.php`	text/x-php	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.php3`	text/x-php	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.php4`	text/x-php	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.pl`	text/x-perl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.pls`	application/pls+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.pm`	text/x-perl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.png`	image/png	ImageParser +OCR	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.pod`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.pom`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.pot`	application/vnd.ms-powerpoint	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.potm`	application/vnd.ms-powerpoint.template.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.potx`	application/vnd.openxmlformats-officedocument.presentationml.template	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.pp`	text/x-pascal	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ppa`	application/vnd.ms-powerpoint	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.ppam`	application/vnd.ms-powerpoint.addin.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.ppj`	image/vnd.adobe.premiere	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.pps`	application/vnd.ms-powerpoint	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.ppsm`	application/vnd.ms-powerpoint.slideshow.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.ppsx`	application/vnd.openxmlformats-officedocument.presentationml.slideshow	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.ppt`	application/vnd.ms-powerpoint	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.pptm`	application/vnd.ms-powerpoint.presentation.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.pptx`	application/vnd.openxmlformats-officedocument.presentationml.presentation	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.ppz`	application/vnd.ms-powerpoint	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.pro`	text/x-prolog	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.project`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.properties`	text/x-java-properties	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.prt`	application/x-prt	PRTParser	structural metadata from this CAD/manufacturing part format — not readable prose.
`.psd`	image/vnd.adobe.photoshop	PSDParser	layer names and image metadata from a .psd file — not OCR, and not layer contents rendered as an image.
`.pst`	application/vnd.ms-outlook-pst	OutlookPSTParser	every message in the .pst/.ost mail store parsed individually — this is a whole mailbox, not a single email (see RFC822Parser/the email guide for a single .eml/.msg).
`.pub`	application/x-mspublisher	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.py`	text/x-python	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.qpw`	application/x-quattro-pro	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.qt`	video/quicktime	MP4Parser	the container's tag metadata (title, duration, codec) for MP4-family video and audio — never a transcript of spoken words.
`.r`	text/x-rsrc	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.rar`	application/x-rar-compressed	RarParser	every file inside the archive extracted and recursed, the same as the ZIP/7z path.
`.rb`	text/x-ruby	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.rdf`	application/rdf+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.res`	application/x-dtbresource+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.rest`	text/x-rst	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.restx`	text/x-rst	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.rexx`	text/x-rexx	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.rif`	application/reginfo+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.rl`	application/resource-lists+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.rld`	application/resource-lists-diff+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.rmi`	audio/midi	MidiParser	track and instrument metadata from a MIDI file — MIDI encodes notes, not sound or speech, so there's nothing to transcribe.
`.rnc`	application/relax-ng-compact-syntax	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.rng`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.rnx`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.roff`	text/troff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.roles`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.rs`	application/rls-services+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.rsd`	application/rsd+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.rss`	application/rss+xml	FeedParser	every entry's title, summary, and body text pulled out of the feed, not just the feed's own metadata.
`.rst`	text/x-rst	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.rtf`	application/rtf	RTFParser	the document body text, control words and named special characters resolved to their actual characters.
`.rtx`	text/richtext	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.s`	text/x-assembly	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.sas`	application/x-sas	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.sas7bdat`	application/x-sas-data	SAS7BDATParser	column names and row values from a SAS statistical dataset, as text.
`.sbml`	application/sbml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.scad`	application/x-openscad	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.scala`	text/x-scala	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.schemas`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.scm`	text/x-scheme	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.scurl`	text/vnd.curl.scurl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.sd7`	application/x-sas-data	SAS7BDATParser	column names and row values from a SAS statistical dataset, as text.
`.sda`	application/vnd.stardivision.draw	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.sdc`	application/vnd.stardivision.calc	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.sdd`	application/vnd.stardivision.impress	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.sdkd`	application/vnd.solent.sdkm+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.sdkm`	application/vnd.solent.sdkm+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.sdw`	application/vnd.stardivision.writer	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.sed`	text/x-sed	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.sfdu`	application/x-sfdu	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.sgm`	text/sgml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.sgml`	text/sgml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.sh`	application/x-sh	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.shf`	application/shf+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.shw`	application/x-corelpresentations	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.sldasm`	application/sldworks	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.slddrw`	application/sldworks	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.sldm`	application/vnd.ms-powerpoint.slide.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.sldprt`	application/sldworks	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.sldx`	application/vnd.openxmlformats-officedocument.presentationml.slide	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.smi`	application/smil+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.smil`	application/smil+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.sml`	application/smil+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.snd`	audio/basic	AudioParser	container-level metadata (sample rate, channels, duration) for uncompressed/basic audio formats — never a transcript.
`.spot`	text/vnd.in3d.spot	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.spx`	audio/speex	SpeexParser	the codec's comment-header tags — never a transcript.
`.sql`	text/x-sql	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.srt`	application/x-subrip	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.srx`	application/sparql-results+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.ssml`	application/ssml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.st`	text/x-stsrc	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.stw`	application/vnd.sun.xml.writer.template	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.svg`	image/svg+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.svgz`	image/svg+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.sxc`	application/vnd.sun.xml.calc	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.sxd`	application/vnd.sun.xml.draw	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.sxi`	application/vnd.sun.xml.impress	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.sxw`	application/vnd.sun.xml.writer	OpenDocumentParser	the document body text from ODF files (LibreOffice/OpenOffice's native zipped format) — text, spreadsheet, presentation, and drawing variants alike.
`.t`	text/troff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.tar`	application/x-tar	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.tbz`	application/x-bzip	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.tbz2`	application/x-bzip2	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.tcl`	text/x-tcl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.tex`	application/x-tex	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.text`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.tgz`	application/gzip	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.thmx`	application/vnd.openxmlformats-officedocument.presentationml.presentation	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.tif`	image/tiff	TiffParser +OCR	dimensions and embedded EXIF tags — no OCR from this parser alone (TIFF gets real OCR in production; see the Tesseract note below).
`.tiff`	image/tiff	TiffParser +OCR	dimensions and embedded EXIF tags — no OCR from this parser alone (TIFF gets real OCR in production; see the Tesseract note below).
`.tk`	text/x-tcl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.tld`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.tmx`	application/x-tmx	TMXParser	every translation unit's source and target text pulled from the TMX file.
`.tr`	text/troff	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.tsd`	application/timestamped-data	TSDParser	the timestamp and signer metadata wrapping a signed payload — not the payload's own content.
`.tsv`	text/tab-separated-values	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.ttc`	application/x-font-ttf	TrueTypeParser	the font's name table and other embedded metadata — again, no prose in a font file.
`.ttf`	application/x-font-ttf	TrueTypeParser	the font's name table and other embedded metadata — again, no prose in a font file.
`.ttml`	application/ttml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.txt`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.types`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.udeb`	application/x-debian-package	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.uoml`	application/vnd.uoml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.uri`	text/uri-list	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.uris`	text/uri-list	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.urls`	text/uri-list	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.uu`	text/x-uuencode	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.v`	text/x-verilog	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vb`	text/x-vbdotnet	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vbs`	text/x-vbscript	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vcf`	text/x-vcard	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vcs`	text/x-vcalendar	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vhd`	text/x-vhdl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vhdl`	text/x-vhdl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vm`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vor`	application/x-staroffice-template	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.vsd`	application/vnd.visio	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.vsdm`	application/vnd.ms-visio.drawing.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.vsdx`	application/vnd.ms-visio.drawing	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.vsl`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vss`	application/vnd.visio	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.vssm`	application/vnd.ms-visio.stencil.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.vssx`	application/vnd.ms-visio.stencil	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.vst`	application/vnd.visio	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.vstm`	application/vnd.ms-visio.template.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.vstx`	application/vnd.ms-visio.template	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.vsw`	application/vnd.visio	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.vtt`	text/vtt	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.vxml`	application/voicexml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.war`	application/x-tika-java-web-archive	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.warc`	application/warc	WARCParser	each captured HTTP response unpacked and re-run through detection — a page crawled into a WARC comes back as that page's extracted text.
`.wav`	audio/vnd.wave	AudioParser	container-level metadata (sample rate, channels, duration) for uncompressed/basic audio formats — never a transcript.
`.wb1`	application/x-quattro-pro	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wb2`	application/x-quattro-pro	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wb3`	application/x-quattro-pro	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wbmp`	image/vnd.wap.wbmp	ImageParser	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.wbs`	application/vnd.criticaltools.wbs+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.wcm`	application/vnd.ms-works	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wdb`	application/vnd.ms-works	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.webarchive`	application/x-webarchive	PListParser	the key/value structure of an Apple binary property list, as text — used for a handful of Apple-adjacent formats, not general documents.
`.webmanifest`	application/manifest+json	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.webp`	image/webp	WebPParser +OCR	container metadata — no OCR from this parser alone (WebP gets real OCR in production; see the Tesseract note below).
`.wkq`	application/x-quattro-pro	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wks`	application/vnd.ms-works	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wl`	application/vnd.wolfram.wl	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.wmf`	image/wmf	WMFParser	header metadata from this older vector graphics format — not OCR; WMF is drawing commands, not a photographed page.
`.wml`	text/vnd.wap.wml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.wmls`	text/vnd.wap.wmlscript	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.wmz`	application/x-ms-wmz	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.wps`	application/vnd.ms-works	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wq1`	application/x-quattro-pro	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wq2`	application/x-quattro-pro	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.wsdd`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.wsdl`	application/wsdl+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.wspolicy`	application/wspolicy+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xargs`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xbm`	image/x-xbitmap	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xcat`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xcf`	image/x-xcf	ImageParser	dimensions and embedded EXIF/IPTC tags — no OCR from this parser alone. (Several of the mime types this covers get real OCR in production anyway — see the Tesseract note below.)
`.xconf`	text/x-config	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xdm`	application/vnd.syncml.dm+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xdp`	application/vnd.adobe.xdp+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xegrm`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xenc`	application/xenc+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xer`	application/patch-ops-error+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xfdf`	application/vnd.adobe.xfdf	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xgrm`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xht`	application/xhtml+xml	JSoupParser	the visible page text with boilerplate (nav, scripts, styles) stripped, the same reader behind /tools/html-to-text.
`.xhtml`	application/xhtml+xml	JSoupParser	the visible page text with boilerplate (nav, scripts, styles) stripped, the same reader behind /tools/html-to-text.
`.xhtml2`	application/xhtml+xml	JSoupParser	the visible page text with boilerplate (nav, scripts, styles) stripped, the same reader behind /tools/html-to-text.
`.xhvml`	application/xv+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xla`	application/vnd.ms-excel	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xlam`	application/vnd.ms-excel.addin.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.xlc`	application/vnd.ms-excel	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xld`	application/vnd.ms-excel	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xlex`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xlf`	application/x-xliff+xml	XLIFF12Parser	every translation unit's source and target text from an XLIFF 1.2 file.
`.xliff`	application/x-xliff+xml	XLIFF12Parser	every translation unit's source and target text from an XLIFF 1.2 file.
`.xll`	application/vnd.ms-excel	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xlm`	application/vnd.ms-excel	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xlog`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xlr`	application/x-tika-msworks-spreadsheet	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xls`	application/vnd.ms-excel	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xlsb`	application/vnd.ms-excel.sheet.binary.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.xlsm`	application/vnd.ms-excel.sheet.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.xlsx`	application/vnd.openxmlformats-officedocument.spreadsheetml.sheet	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.xlt`	application/vnd.ms-excel	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xltm`	application/vnd.ms-excel.template.macroenabled.12	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.xltx`	application/vnd.openxmlformats-officedocument.spreadsheetml.template	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.xlw`	application/vnd.ms-excel	OfficeParser	the document body text from old-format Word/Excel/PowerPoint/Outlook/Project/Visio files — the pre-2007 binary formats, not the OOXML zips.
`.xlz`	application/x-xliff+zip	XLZParser	the same translation-unit text as XLIFF12Parser, unpacked from XLIFF's zipped variant first.
`.xmap`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xmind`	application/x-xmind	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.xml`	application/xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xmp`	application/rdf+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xop`	application/xop+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xps`	application/vnd.ms-xpsdocument	OOXMLParser	the document body text from .docx/.xlsx/.pptx-family files, including macro-enabled and template variants, plus embedded content Word/Excel/PowerPoint themselves would show you.
`.xq`	application/xquery	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xquery`	application/xquery	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xroles`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xsamples`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xsd`	application/xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xsl`	application/xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xslfo`	application/xslfo+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xslt`	application/xslt+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xsm`	application/vnd.syncml+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xsp`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xspf`	application/xspf+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xtest`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xul`	application/vnd.mozilla.xul+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xvm`	application/xv+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xvml`	application/xv+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.xweb`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xwelcome`	text/plain	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.xz`	application/x-xz	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.y`	text/x-yacc	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.yaml`	text/x-yaml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.yml`	text/x-yaml	TextAndCSVParser	the raw text, decoded from whichever character set it auto-detects, with delimited data (CSV/TSV) also parsed into rows and columns. This is why source code, config, and markup-adjacent plain-text files (.py, .json, .yaml, .md, and hundreds of others) all just work: they're subtypes of text/plain.
`.z`	application/x-compress	CompressorParser	whatever the compressed stream contains, decompressed and then run back through detection — a .gz wrapping a PDF comes back as that PDF's text, not a description of gzip.
`.zaz`	application/vnd.zzazz.deck+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.
`.zip`	application/zip	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.zipx`	application/zip	PackageParser	every file inside the archive extracted and recursed — each member gets its own pass through the same detection-and-parsing pipeline, so a .zip full of PDFs comes back with all of their text, not just filenames.
`.zmm`	application/vnd.handheld-entertainment+xml	DcXMLParser	the Dublin Core / OOXML-style metadata fields — title, author, dates — plus any text content the schema carries. The biggest single bucket here: most of it is XML-based application formats (feeds, office-adjacent XML dialects, 3D/CAD interchange formats) that share this generic reader.

detect-only

683 extensions Tika names correctly but has no parser for in this build. Sending one of these to the API returns the identified content type and an extraction error, not a fabricated result.

Counted by media type rather than by extension, 1,068 of the 1,683 types this build detects have no parser. This table can only show the 534 of them that register a file extension. The other 534 are known to Tika by media type alone. The lookup above covers all of them either way.

Extension	Media type	Description
`.123`	application/vnd.lotus-1-2-3	Lotus 1-2-3
`.3ds`	image/x-3ds	3D Studio (V1)
`.3fr`	image/x-raw-hasselblad	Hasselblad raw image
`.aab`	application/x-authorware-bin	—
`.aac`	audio/x-aac	—
`.aam`	application/x-authorware-map	—
`.aas`	application/x-authorware-seg	—
`.abw`	application/x-abiword	—
`.ac3`	audio/ac3	Dolby Digital Audio Compression File
`.acc`	application/vnd.americandynamics.acc	—
`.ace`	application/x-ace-compressed	—
`.acu`	application/vnd.acucobol	—
`.acutc`	application/vnd.acucorp	—
`.adf`	application/x-amiga-disk-format	Amiga Disk File
`.adp`	audio/adpcm	—
`.aep`	application/vnd.adobe.aftereffects.project	—
`.aet`	application/vnd.adobe.aftereffects.template	—
`.afp`	application/vnd.ibm.modcap	—
`.ami`	application/vnd.amiga.ami	—
`.amr`	audio/amr	—
`.application`	application/x-ms-application	—
`.apr`	application/vnd.lotus-approach	—
`.arw`	image/x-raw-sony	Sony raw image
`.asc`	application/pgp-signature	—
`.asf`	video/x-ms-asf	—
`.asnd`	audio/vnd.adobe.soundbooth	—
`.aso`	application/vnd.accpac.simply.aso	—
`.atc`	application/vnd.acucorp	—
`.atx`	application/vnd.antix.game-component	—
`.avi`	video/x-msvideo	Audio Video Interleave File
`.avif`	image/avif	AV1 Image File
`.aw`	application/applixware	—
`.axx`	application/x-axcrypt	AxCrypt
`.azf`	application/vnd.airzip.filesecure.azf	—
`.azs`	application/vnd.airzip.filesecure.azs	—
`.azw`	application/vnd.amazon.ebook	—
`.bay`	image/x-raw-casio	Casio raw image
`.bcpio`	application/x-bcpio	—
`.bdf`	application/x-font-bdf	—
`.bdm`	application/vnd.syncml.dm+wbxml	—
`.bh2`	application/vnd.fujitsu.oasysprs	—
`.bin`	application/octet-stream	—
`.bmi`	application/vnd.bmi	—
`.book`	application/vnd.framemaker	—
`.box`	application/vnd.previewsystems.box	—
`.bpk`	application/octet-stream	—
`.btif`	image/prs.btif	—
`.bup`	application/x-dvd-ifo	DVD information file
`.c4d`	application/vnd.clonk.c4group	—
`.c4f`	application/vnd.clonk.c4group	—
`.c4g`	application/vnd.clonk.c4group	—
`.c4p`	application/vnd.clonk.c4group	—
`.c4u`	application/vnd.clonk.c4group	—
`.cab`	application/vnd.ms-cab-compressed	—
`.caf`	audio/x-caf	com.apple.coreaudio-format
`.cap`	application/vnd.tcpdump.pcap	TCPDump pcap packet capture
`.car`	application/vnd.curl.car	—
`.cat`	application/vnd.ms-pki.seccat	—
`.cbor`	application/cbor	Concise Binary Object Representation container
`.cct`	application/x-director	Shockwave Movie
`.cda`	application/x-cdf	CD Audio
`.cdbcmsg`	application/vnd.contact.cmsg	—
`.cdf`	application/x-netcdf	—
`.cdkey`	application/vnd.mediastation.cdkey	—
`.cdr`	application/coreldraw	des: CorelDraw X4 and newer
`.cdx`	chemical/x-cdx	—
`.cdy`	application/vnd.cinderella	—
`.cel`	image/vnd.dgn	—
`.cer`	application/pkix-cert	—
`.cgm`	image/cgm	Computer Graphics Metafile
`.chat`	application/x-chat	—
`.chrt`	application/vnd.kde.kchart	KChart File
`.cif`	chemical/x-cif	—
`.cii`	application/vnd.anser-web-certificate-issue-initiation	—
`.cil`	application/vnd.ms-artgalry	—
`.cla`	application/vnd.claymore	—
`.clkk`	application/vnd.crick.clicker.keyboard	—
`.clkp`	application/vnd.crick.clicker.palette	—
`.clkt`	application/vnd.crick.clicker.template	—
`.clkw`	application/vnd.crick.clicker.wordbank	—
`.clkx`	application/vnd.crick.clicker	—
`.clp`	application/x-msclip	—
`.cmc`	application/vnd.cosmocaller	—
`.cmdf`	chemical/x-cmdf	—
`.cml`	chemical/x-cml	—
`.cmp`	application/vnd.yellowriver-custom-menu	—
`.cmx`	image/x-cmx	—
`.cod`	application/vnd.rim.cod	—
`.cpt`	application/mac-compactpro	—
`.crd`	application/x-mscardfile	—
`.crl`	application/pkix-crl	—
`.crt`	application/x-x509-cert	—
`.crw`	image/x-raw-canon	Canon raw image
`.crx`	application/x-chrome-package	Chrome Extension Package
`.csh`	application/x-csh	—
`.csml`	chemical/x-csml	—
`.csp`	application/vnd.commonspace	—
`.cst`	application/x-director	Shockwave Movie
`.cu`	application/cu-seeme	—
`.cwk`	application/x-appleworks	—
`.cww`	application/prs.cww	—
`.cxt`	application/x-director	Shockwave Movie
`.daf`	application/vnd.mobius.daf	—
`.dataless`	application/vnd.fdsn.seed	—
`.dcr`	application/x-director	Shockwave Movie
`.dcs`	image/x-raw-kodak	Kodak raw image
`.dcx`	image/vnd.zbrush.dcx	ZSoft Multi-Page Paintbrush
`.ddd`	application/vnd.fujixerox.ddd	—
`.deploy`	application/octet-stream	—
`.der`	application/x-x509-cert; format=der	—
`.dex`	application/x-dex	Dalvik Executable Format
`.dfac`	application/vnd.dreamfactory	—
`.dgn`	image/vnd.dgn	—
`.dgnlib`	image/vnd.dgn	—
`.dir`	application/x-director	Shockwave Movie
`.dis`	application/vnd.mobius.dis	—
`.dist`	application/octet-stream	—
`.distz`	application/octet-stream	—
`.djv`	image/vnd.djvu	—
`.djvu`	image/vnd.djvu	—
`.dmg`	application/x-apple-diskimage	—
`.dmp`	application/vnd.tcpdump.pcap	TCPDump pcap packet capture
`.dms`	application/octet-stream	—
`.dna`	application/vnd.dna	—
`.dng`	image/x-raw-adobe	Adobe Digital Negative
`.do`	application/x-stata-do	Stata DTA Script
`.dp`	application/vnd.osgi.dp	—
`.dpg`	application/vnd.dpgraph	—
`.dpx`	image/x-dpx	Digital Picture Exchange from SMPTE
`.drf`	image/x-raw-kodak	Kodak raw image
`.dta`	application/x-stata-dta	Stata DTA Dataset
`.dts`	audio/vnd.dts	—
`.dtshd`	audio/vnd.dts.hd	—
`.dump`	application/octet-stream	—
`.dvi`	application/x-dvi	TeX Device Independent Document
`.dwf`	model/vnd.dwf	AutoCAD Design Web Format
`.dxb`	image/vnd.dxb	AutoCAD DXF simplified Binary
`.dxf`	image/vnd.dxf	AutoCAD DXF
`.dxp`	application/vnd.spotfire.dxp	—
`.dxr`	application/x-director	Shockwave Movie
`.e57`	model/e57	3d imaging data exchange
`.ecelp4800`	audio/vnd.nuera.ecelp4800	—
`.ecelp7470`	audio/vnd.nuera.ecelp7470	—
`.ecelp9600`	audio/vnd.nuera.ecelp9600	—
`.ecma`	application/ecmascript	—
`.edm`	application/vnd.novadigm.edm	—
`.edx`	application/vnd.novadigm.edx	—
`.efif`	application/vnd.picsel	—
`.ei6`	application/vnd.pg.osasli	—
`.elc`	application/octet-stream	—
`.enr`	application/x-endnote-refer	—
`.ens`	application/x-endnote-style	—
`.enw`	application/x-endnote-refer	—
`.eol`	audio/vnd.digital-winds	—
`.eot`	application/vnd.ms-fontobject	—
`.eps`	application/postscript	PostScript
`.epsf`	application/postscript	PostScript
`.epsi`	application/postscript	PostScript
`.erf`	image/x-raw-epson	Epson raw image
`.esf`	application/vnd.epson.esf	—
`.exr`	image/aces	ACES Image Container File
`.ext`	application/vnd.novadigm.ext	—
`.ez`	application/andrew-inset	—
`.ez2`	application/vnd.ezpix-album	—
`.ez3`	application/vnd.ezpix-package	—
`.f4v`	video/x-f4v	—
`.fbs`	image/vnd.fastbidsheet	—
`.fcs`	application/vnd.isac.fcs	Flow Cytometry Standard File
`.fdf`	application/vnd.fdf	Forms Data Format
`.fff`	image/x-raw-imacon	Imacon raw image
`.fg5`	application/vnd.fujitsu.oasysgp	—
`.fgd`	application/x-director	Shockwave Movie
`.fh`	image/x-freehand	FreeHand image
`.fh10`	image/x-freehand	FreeHand image
`.fh11`	image/x-freehand	FreeHand image
`.fh12`	image/x-freehand	FreeHand image
`.fh4`	image/x-freehand	FreeHand image
`.fh40`	image/x-freehand	FreeHand image
`.fh5`	image/x-freehand	FreeHand image
`.fh50`	image/x-freehand	FreeHand image
`.fh7`	image/x-freehand	FreeHand image
`.fh8`	image/x-freehand	FreeHand image
`.fh9`	image/x-freehand	FreeHand image
`.fhc`	image/x-freehand	FreeHand image
`.fig`	application/x-xfig	—
`.fit`	application/fits	Flexible Image Transport System
`.fits`	application/fits	Flexible Image Transport System
`.flc`	video/x-flc	—
`.fli`	video/x-fli	—
`.flo`	application/vnd.micrografx.flo	—
`.flw`	application/vnd.kde.kivio	—
`.fm`	application/vnd.framemaker	—
`.fnc`	application/vnd.frogans.fnc	—
`.fp7`	application/x-filemaker	FileMaker Pro 7
`.fpx`	image/vnd.fpx	—
`.frame`	application/vnd.framemaker	—
`.fsc`	application/vnd.fsc.weblaunch	—
`.fst`	image/vnd.fst	—
`.ft10`	image/x-freehand	FreeHand image
`.ft11`	image/x-freehand	FreeHand image
`.ft12`	image/x-freehand	FreeHand image
`.ft7`	image/x-freehand	FreeHand image
`.ft8`	image/x-freehand	FreeHand image
`.ft9`	image/x-freehand	FreeHand image
`.ftc`	application/vnd.fluxtime.clip	—
`.fti`	application/vnd.anser-web-funds-transfer-initiation	—
`.fts`	application/fits	Flexible Image Transport System
`.fvt`	video/vnd.fvt	—
`.fzs`	application/vnd.fuzzysheet	—
`.g3`	image/g3fax	—
`.gac`	application/vnd.groove-account	—
`.gdl`	model/vnd.gdl	—
`.geo`	application/vnd.dynageo	—
`.gex`	application/vnd.geometry-explorer	—
`.ggb`	application/vnd.geogebra.file	—
`.ggt`	application/vnd.geogebra.tool	—
`.ghf`	application/vnd.groove-help	—
`.gim`	application/vnd.groove-identity-message	—
`.gmx`	application/vnd.gmx	—
`.gnucash`	application/x-gnucash	—
`.gnumeric`	application/x-gnumeric	—
`.gp4`	application/x-guitar-pro	Guitar Pro
`.gpg`	application/pgp-encrypted	—
`.gph`	application/vnd.flographit	—
`.gpkg`	application/x-geopackage	—
`.gqf`	application/vnd.grafeq	—
`.gqs`	application/vnd.grafeq	—
`.gram`	application/srgs	—
`.grb`	application/x-grib	General Regularly-distributed Information in Binary form
`.grb1`	application/x-grib	General Regularly-distributed Information in Binary form
`.grb2`	application/x-grib	General Regularly-distributed Information in Binary form
`.gre`	application/vnd.geometry-explorer	—
`.grv`	application/vnd.groove-injector	—
`.gsf`	application/x-font-ghostscript	—
`.gslib`	audio/x-psf	Portable Sound Format
`.gtm`	application/vnd.groove-tool-message	—
`.gtw`	model/vnd.gtw	—
`.h261`	video/h261	—
`.h263`	video/h263	—
`.h264`	video/h264	—
`.h5`	application/x-hdf	Hierarchical Data Format File
`.hbci`	application/vnd.hbci	—
`.hdf`	application/x-hdf	Hierarchical Data Format File
`.hdr`	application/envi.hdr	—
`.he5`	application/x-hdf	Hierarchical Data Format File
`.hfa`	application/x-erdas-hfa	—
`.hlp`	application/winhlp	—
`.hpgl`	application/vnd.hp-hpgl	—
`.hpid`	application/vnd.hp-hpid	—
`.hprof`	application/vnd.java.hprof	Java hprof text file
`.hps`	application/vnd.hp-hps	—
`.hqx`	application/mac-binhex40	—
`.htke`	application/vnd.kenameaapp	—
`.hvd`	application/vnd.yamaha.hv-dic	—
`.hvp`	application/vnd.yamaha.hv-voice	—
`.hvs`	application/vnd.yamaha.hv-script	—
`.icb`	image/x-tga	Targa image data
`.icc`	application/vnd.iccprofile	—
`.ice`	x-conference/x-cooltalk	Cooltalk Audio
`.icm`	application/vnd.iccprofile	—
`.ief`	image/ief	—
`.ifm`	application/vnd.shana.informed.formdata	—
`.ifo`	application/x-dvd-ifo	DVD information file
`.iges`	model/iges	Initial Graphics Exchange Specification Format
`.igl`	application/vnd.igloader	—
`.igs`	model/iges	Initial Graphics Exchange Specification Format
`.igx`	application/vnd.micrografx.igx	—
`.iif`	application/vnd.shana.informed.interchange	—
`.iiq`	image/x-raw-phaseone	Phase One raw image
`.imp`	application/vnd.accpac.simply.imp	—
`.ims`	application/vnd.ms-ims	—
`.indd`	application/x-adobe-indesign	Adobe InDesign document
`.ipk`	application/vnd.shana.informed.package	—
`.irm`	application/vnd.ibm.rights-management	—
`.iso`	application/x-iso9660-image	ISO 9660 CD-ROM filesystem data
`.itp`	application/vnd.shana.informed.formtemplate	—
`.ivp`	application/vnd.immervision-ivp	—
`.ivu`	application/vnd.immervision-ivu	—
`.j2c`	image/x-jp2-codestream	JPEG 2000 Codestream
`.jam`	application/vnd.jam	—
`.jdf`	application/x-jeol-jdf	JDF NMR Spectroscopy
`.jisp`	application/vnd.jisp	—
`.jks`	application/x-java-keystore	Java Keystore
`.jlt`	application/vnd.hp-jlyt	—
`.jng`	video/x-jng	—
`.jnlp`	application/x-java-jnlp-file	—
`.joda`	application/vnd.joost.joda-archive	—
`.jp2`	image/jp2	JPEG 2000 Part 1 (JP2)
`.jpf`	image/jpx	JPEG 2000 Part 2 (JPX)
`.jpgm`	image/jpm	JPEG 2000 Part 6 (JPM)
`.jpgv`	video/jpeg	—
`.jpm`	image/jpm	JPEG 2000 Part 6 (JPM)
`.k25`	image/x-raw-kodak	Kodak raw image
`.karbon`	application/vnd.kde.karbon	—
`.kdc`	image/x-raw-kodak	Kodak raw image
`.kfo`	application/vnd.kde.kformula	—
`.kia`	application/vnd.kidspiration	—
`.kil`	application/x-killustrator	KIllustrator File
`.kne`	application/vnd.kinar	—
`.knp`	application/vnd.kinar	—
`.kon`	application/vnd.kde.kontour	—
`.kpr`	application/vnd.kde.kpresenter	KPresenter File
`.kpt`	application/vnd.kde.kpresenter	KPresenter File
`.ksp`	application/vnd.kde.kspread	KSpread File
`.ktr`	application/vnd.kahootz	—
`.ktz`	application/vnd.kahootz	—
`.kwd`	application/vnd.kde.kword	KWord File
`.kwt`	application/vnd.kde.kword	KWord File
`.las`	application/x-asprs	ASPRS Lidar Data Exchange Format
`.laz`	application/x-asprs	ASPRS Lidar Data Exchange Format
`.lbd`	application/vnd.llamagraphics.life-balance.desktop	—
`.les`	application/vnd.hhe.lesson-player	—
`.lha`	application/octet-stream	—
`.list3820`	application/vnd.ibm.modcap	—
`.listafp`	application/vnd.ibm.modcap	—
`.lrf`	application/octet-stream	—
`.lrm`	application/vnd.ms-lrm	—
`.ltf`	application/vnd.frogans.ltf	—
`.lvp`	audio/vnd.lucent.voice	—
`.lwp`	application/vnd.lotus-wordpro	—
`.lz`	application/x-lzip	Lzip (LZMA) compressed archive
`.lzh`	application/octet-stream	—
`.m13`	application/x-msmediaview	—
`.m14`	application/x-msmediaview	—
`.m1v`	video/mpeg	MPEG Movie Clip
`.m2v`	video/mpeg	MPEG Movie Clip
`.m3u`	audio/x-mpegurl	MP3 Playlist File
`.m3u8`	application/vnd.apple.mpegurl	—
`.m4u`	video/vnd.mpegurl	—
`.mag`	application/vnd.ecowin.chart	—
`.maker`	application/vnd.framemaker	—
`.mbk`	application/vnd.mobius.mbk	—
`.mc1`	application/vnd.medcalcdata	—
`.mcd`	application/vnd.mcd	—
`.mdi`	image/vnd.ms-modi	Microsoft Document Imaging
`.mef`	image/x-raw-mamiya	Mamiya raw image
`.mesh`	model/mesh	—
`.mfm`	application/vnd.mfmp	—
`.mgz`	application/vnd.proteus.magazine	—
`.minigsf`	audio/x-psf	Portable Sound Format
`.minipsf`	audio/x-psf	Portable Sound Format
`.minipsf1`	audio/x-psf	Portable Sound Format
`.mj2`	video/mj2	JPEG 2000 Part 3 (Motion JPEG, MJ2)
`.mjp2`	video/mj2	JPEG 2000 Part 3 (Motion JPEG, MJ2)
`.mka`	audio/x-matroska	—
`.mkv`	video/x-matroska	—
`.mlp`	application/vnd.dolby.mlp	—
`.mmd`	application/vnd.chipnuts.karaoke-mmd	—
`.mmf`	application/vnd.smaf	—
`.mmr`	image/vnd.fujixerox.edmics-mmr	—
`.mng`	video/x-mng	—
`.mny`	application/x-msmoney	—
`.mobi`	application/x-mobipocket-ebook	Mobipocket Ebook
`.mod`	audio/x-mod	—
`.mos`	image/x-raw-leaf	Leaf raw image
`.movie`	video/x-sgi-movie	—
`.mpc`	application/vnd.mophun.certificate	—
`.mpe`	video/mpeg	MPEG Movie Clip
`.mpeg`	video/mpeg	MPEG Movie Clip
`.mpg`	video/mpeg	MPEG Movie Clip
`.mpm`	application/vnd.blueice.multipass	—
`.mpn`	application/vnd.mophun.application	—
`.mpy`	application/vnd.ibm.minipay	—
`.mqy`	application/vnd.mobius.mqy	—
`.mrc`	application/marc	—
`.mrw`	image/x-raw-minolta	Minolta raw image
`.msa`	application/vnd.msa-disk-image	Magic Shadow Archiver
`.mseed`	application/vnd.fdsn.mseed	—
`.mseq`	application/vnd.mseq	—
`.msf`	application/vnd.epson.msf	—
`.msh`	model/mesh	—
`.msl`	application/vnd.mobius.msl	—
`.msty`	application/vnd.muvee.style	—
`.mts`	model/vnd.mts	—
`.mus`	application/vnd.musician	—
`.mvb`	application/x-msmediaview	—
`.mwf`	application/vnd.mfer	—
`.mxf`	application/mxf	—
`.mxl`	application/vnd.recordare.musicxml	—
`.mxs`	application/vnd.triscape.mxs	—
`.mxu`	video/vnd.mpegurl	—
`.myd`	application/x-mysql-misam-data	MySQL MISAM Data
`.myi`	application/x-mysql-misam-compressed-index	MySQL MISAM Compressed Index
`.nc`	application/x-netcdf	—
`.nef`	image/x-raw-nikon	Nikon raw image
`.nes`	application/x-nesrom	Nintendo Entertainment System ROM
`.ngdat`	application/vnd.nokia.n-gage.data	—
`.nitf`	image/nitf	—
`.nlu`	application/vnd.neurolanguage.nlu	—
`.nml`	application/vnd.enliven	—
`.nnd`	application/vnd.noblenet-directory	—
`.nns`	application/vnd.noblenet-sealer	—
`.nnw`	application/vnd.noblenet-web	—
`.npx`	image/vnd.net-fpx	—
`.nrw`	image/x-raw-nikon	Nikon raw image
`.nsf`	application/vnd.lotus-notes	—
`.ntf`	image/nitf	—
`.oa2`	application/vnd.fujitsu.oasys2	—
`.oa3`	application/vnd.fujitsu.oasys3	—
`.oas`	application/vnd.fujitsu.oasys	—
`.obd`	application/x-msbinder	—
`.oda`	application/oda	—
`.odb`	application/vnd.oasis.opendocument.base	—
`.onepkg`	application/onenote; format=package	OneNote Package
`.onetmp`	application/onenote	—
`.onetoc`	application/onenote; format=onetoc2	OneNote Table of Contents
`.onetoc2`	application/onenote; format=onetoc2	OneNote Table of Contents
`.oprc`	application/vnd.palm	—
`.orf`	image/x-raw-olympus	Olympus raw image
`.org`	application/vnd.lotus-organizer	—
`.osf`	application/vnd.yamaha.openscoreformat	—
`.otf`	application/x-font-otf	OpenType Font
`.p10`	application/pkcs10	—
`.p12`	application/x-pkcs12	—
`.p7b`	application/x-pkcs7-certificates	—
`.p7r`	application/x-pkcs7-certreqresp	—
`.pam`	image/x-portable-arbitrarymap	UNIX Portable Bitmap Graphic Arbitrary Map
`.parquet`	application/x-parquet	—
`.pbd`	application/vnd.powerbuilder6	—
`.pbm`	image/x-portable-bitmap	Portable Bit Map
`.pcap`	application/vnd.tcpdump.pcap	TCPDump pcap packet capture
`.pcapng`	application/vnd.tcpdump.pcapng	TCPDump next gen pcap packet capture
`.pcf`	application/x-font-pcf	—
`.pcl`	application/vnd.hp-pcl	—
`.pclxl`	application/vnd.hp-pclxl	—
`.pct`	image/x-pict	Apple Macintosh QuickDraw/PICT Format
`.pcurl`	application/vnd.curl.pcurl	—
`.pcx`	image/vnd.zbrush.pcx	ZSoft Paintbrush PiCture eXchange
`.pdb`	chemical/x-pdb	Brookhaven Protein Databank File
`.pef`	image/x-raw-pentax	Pentax raw image
`.pem`	application/x-x509-cert; format=pem	—
`.pfa`	application/x-font-type1	—
`.pfb`	application/x-font-type1	—
`.pfm`	application/x-font-printer-metric	Printer Font Metric
`.pfr`	application/font-tdpfr	—
`.pfx`	application/x-pkcs12	—
`.pgm`	image/x-portable-graymap	Portable Graymap Graphic
`.pgn`	application/x-chess-pgn	—
`.pgp`	application/pgp-encrypted	—
`.pic`	image/x-pict	Apple Macintosh QuickDraw/PICT Format
`.pict`	image/x-pict	Apple Macintosh QuickDraw/PICT Format
`.pkg`	application/octet-stream	—
`.pki`	application/pkixcmp	—
`.pkipath`	application/pkix-pkipath	—
`.plb`	application/vnd.3gpp.pic-bw-large	—
`.plc`	application/vnd.mobius.plc	—
`.plf`	application/vnd.pocketlearn	—
`.pml`	application/vnd.ctc-posml	—
`.pnm`	image/x-portable-anymap	Portable Any Map
`.portpkg`	application/vnd.macports.portpkg	—
`.ppd`	application/vnd.cups-ppd	—
`.ppm`	image/x-portable-pixmap	UNIX Portable Bitmap Graphic
`.pqa`	application/vnd.palm	—
`.prc`	application/x-mobipocket-ebook	Mobipocket Ebook
`.pre`	application/vnd.lotus-freelance	—
`.prf`	application/pics-rules	—
`.ps`	application/postscript	PostScript
`.psb`	application/vnd.3gpp.pic-bw-small	—
`.psf`	application/x-font-linux-psf	—
`.psf1`	audio/x-psf	Portable Sound Format
`.psflib`	audio/x-psf	Portable Sound Format
`.ptid`	application/vnd.pvi.ptid1	—
`.ptx`	image/x-raw-pentax	Pentax raw image
`.pvb`	application/vnd.3gpp.pic-bw-var	—
`.pwn`	application/vnd.3m.post-it-notes	—
`.pxn`	image/x-raw-logitech	Logitech raw image
`.pya`	audio/vnd.ms-playready.media.pya	—
`.pyv`	video/vnd.ms-playready.media.pyv	—
`.qam`	application/vnd.epson.quickanime	—
`.qbo`	application/vnd.intu.qbo	—
`.qfx`	application/vnd.intu.qfx	—
`.qps`	application/vnd.publishare-delta-tree	—
`.qwd`	application/vnd.quark.quarkxpress	—
`.qwt`	application/vnd.quark.quarkxpress	—
`.qxb`	application/vnd.quark.quarkxpress	—
`.qxd`	application/vnd.quark.quarkxpress	—
`.qxl`	application/vnd.quark.quarkxpress	—
`.qxt`	application/vnd.quark.quarkxpress	—
`.r3d`	image/x-raw-red	Red raw image
`.ra`	audio/x-pn-realaudio	Real Audio
`.raf`	image/x-raw-fuji	Fuji raw image
`.ram`	audio/x-pn-realaudio	Real Audio
`.ras`	image/x-cmu-raster	—
`.raw`	image/x-raw-panasonic	Panasonic raw image
`.rcprofile`	application/vnd.ipunplugged.rcprofile	—
`.rdz`	application/vnd.data-vision.rdz	—
`.rep`	application/vnd.businessobjects	—
`.rgb`	image/x-rgb	Silicon Graphics RGB Bitmap
`.rlc`	image/vnd.fujixerox.edmics-rlc	—
`.rm`	application/vnd.rn-realmedia	—
`.rmp`	audio/x-pn-realaudio-plugin	RealMedia Player Plug-in
`.rms`	application/vnd.jcp.javame.midlet-rms	—
`.rpm`	application/x-rpm	RedHat Package Manager
`.rpss`	application/vnd.nokia.radio-presets	—
`.rpst`	application/vnd.nokia.radio-preset	—
`.rq`	application/sparql-query	—
`.rw2`	image/x-raw-panasonic	Panasonic raw image
`.rwz`	image/x-raw-rawzor	Rawzor raw image
`.s7m`	application/x-sas-dmdb	SAS DMDB Data Mining Database File
`.sa7`	application/x-sas-access	SAS Access Descriptor
`.saf`	application/vnd.yamaha.smaf-audio	—
`.sap`	audio/x-sap	Slight Atari Player
`.sas7bacs`	application/x-sas-access	SAS Access Descriptor
`.sas7baud`	application/x-sas-audit	SAS Audit
`.sas7bbak`	application/x-sas-backup	SAS Backup
`.sas7bcat`	application/x-sas-catalog	SAS Catalog
`.sas7bdmd`	application/x-sas-dmdb	SAS DMDB Data Mining Database File
`.sas7bfdb`	application/x-sas-fdb	SAS FDB Consolidation Database File
`.sas7bitm`	application/x-sas-itemstor	SAS Item Store (ItemStor) File
`.sas7bmdb`	application/x-sas-mddb	SAS MDDB Multi-Dimensional Database File
`.sas7bndx`	application/x-sas-data-index	SAS Data Set Index
`.sas7bpgm`	application/x-sas-program-data	SAS Stored Program (DATA Step)
`.sas7bput`	application/x-sas-putility	SAS Permanent Utility
`.sas7butl`	application/x-sas-utility	SAS Utility
`.sas7bvew`	application/x-sas-view	SAS Data Set View
`.sav`	application/x-spss-sav	SPSS Data File
`.sc`	application/vnd.ibm.secure-container	—
`.sc7`	application/x-sas-catalog	SAS Catalog
`.scd`	application/x-msschedule	—
`.scq`	application/scvp-cv-request	—
`.scs`	application/scvp-cv-response	—
`.sd2`	application/x-sas-data-v6	SAS v6 Data Set
`.sdp`	application/sdp	—
`.see`	application/vnd.seemail	—
`.seed`	application/vnd.fdsn.seed	—
`.sema`	application/vnd.sema	—
`.semd`	application/vnd.semd	—
`.semf`	application/vnd.semf	—
`.ser`	application/java-serialized-object	—
`.setpay`	application/set-payment-initiation	—
`.setreg`	application/set-registration-initiation	—
`.sf7`	application/x-sas-fdb	SAS FDB Consolidation Database File
`.sfs`	application/vnd.spotfire.sfs	—
`.sgl`	application/vnd.stardivision.writer-global	—
`.shar`	application/x-shar	—
`.shp`	application/x-shapefile	ESRI Shapefiles
`.si7`	application/x-sas-data-index	SAS Data Set Index
`.sib`	application/x-sibelius	Sibelius
`.sig`	application/pgp-signature	—
`.silo`	model/mesh	—
`.sis`	application/vnd.symbian.install	—
`.sisx`	application/vnd.symbian.install	—
`.sit`	application/x-stuffit	—
`.sitx`	application/x-stuffitx	—
`.skd`	application/vnd.koan	SSEYO Koan File
`.skm`	application/vnd.koan	SSEYO Koan File
`.skp`	application/vnd.koan	SSEYO Koan File
`.skt`	application/vnd.koan	SSEYO Koan File
`.slt`	application/vnd.epson.salt	—
`.sm7`	application/x-sas-mddb	SAS MDDB Multi-Dimensional Database File
`.smf`	application/vnd.stardivision.math	—
`.snf`	application/x-font-snf	—
`.so`	application/octet-stream	—
`.sp7`	application/x-sas-putility	SAS Permanent Utility
`.spc`	application/x-pkcs7-certificates	—
`.spf`	application/vnd.yamaha.smaf-phrase	—
`.spl`	application/x-futuresplash	Macromedia FutureSplash File
`.spp`	application/scvp-vp-response	—
`.spq`	application/scvp-vp-request	—
`.sr2`	image/x-raw-sony	Sony raw image
`.sr7`	application/x-sas-itemstor	SAS Item Store (ItemStor) File
`.src`	application/x-wais-source	—
`.srf`	image/x-raw-sony	Sony raw image
`.srl`	application/sereal	Sereal binary serialization format
`.ss7`	application/x-sas-program-data	SAS Stored Program (DATA Step)
`.sse`	application/vnd.kodak-descriptor	—
`.ssf`	application/vnd.epson.ssf	—
`.st7`	application/x-sas-audit	SAS Audit
`.stc`	application/vnd.sun.xml.calc.template	—
`.std`	application/vnd.sun.xml.draw.template	—
`.stf`	application/vnd.wt.stf	—
`.sti`	application/vnd.sun.xml.impress.template	—
`.stk`	application/hyperstudio	—
`.stl`	model/x.stl-binary	no magic available
`.str`	application/vnd.pg.format	—
`.stx`	application/x-sas-transport	SAS Transport File
`.su7`	application/x-sas-utility	SAS Utility
`.sus`	application/vnd.sus-calendar	—
`.susp`	application/vnd.sus-calendar	—
`.sv4cpio`	application/x-sv4cpio	—
`.sv4crc`	application/x-sv4crc	—
`.sv7`	application/x-sas-view	SAS Data Set View
`.svd`	application/vnd.svd	—
`.swa`	application/x-director	Shockwave Movie
`.swf`	application/x-shockwave-flash	Adobe Flash
`.swi`	application/vnd.arastra.swi	—
`.sxg`	application/vnd.sun.xml.writer.global	—
`.sxm`	application/vnd.sun.xml.math	—
`.sz`	application/x-snappy-framed	Snappy Framed
`.tao`	application/vnd.tao.intent-module-archive	—
`.tcap`	application/vnd.3gpp2.tcap	—
`.tcsh`	application/x-csh	—
`.teacher`	application/vnd.smart.teacher	—
`.texi`	application/x-texinfo	—
`.texinfo`	application/x-texinfo	—
`.tfm`	application/x-tex-tfm	—
`.tga`	image/x-tga	Targa image data
`.tmo`	application/vnd.tmobile-livetv	—
`.toast`	application/x-roxio-toast	—
`.torrent`	application/x-bittorrent	—
`.tpl`	application/vnd.groove-tool-template	—
`.tpt`	application/vnd.trid.tpt	—
`.tra`	application/vnd.trueapp	—
`.trm`	application/x-msterminal	—
`.twd`	application/vnd.simtech-mindmapper	—
`.twds`	application/vnd.simtech-mindmapper	—
`.txd`	application/vnd.genomatix.tuxedo	—
`.txf`	application/vnd.mobius.txf	—
`.tzx`	application/x-spectrum-tzx	TAP (ZX Spectrum)
`.u32`	application/x-authorware-bin	—
`.uc2`	application/x-uc2-compressed	—
`.ufd`	application/vnd.ufdl	—
`.ufdl`	application/vnd.ufdl	—
`.umj`	application/vnd.umajin	—
`.unityweb`	application/vnd.unity	—
`.ustar`	application/x-ustar	—
`.utz`	application/vnd.uiq.theme	—
`.vcd`	application/x-cdlink	Virtual CD-ROM CD Image File
`.vcg`	application/vnd.groove-vcard	—
`.vcx`	application/vnd.vcx	—
`.vda`	image/x-tga	Targa image data
`.vf`	application/x-tex-virtual-font	TeX Virtual Font format
`.vis`	application/vnd.visionary	—
`.viv`	video/vnd.vivo	—
`.vmdk`	application/x-vmdk	Virtual Disk Format
`.vox`	application/x-authorware-bin	—
`.vrml`	model/vrml	—
`.vsf`	application/vnd.vsf	—
`.vtu`	model/vnd.vtu	—
`.w3d`	application/x-director	Shockwave Movie
`.w60`	application/vnd.wordperfect	WordPerfect - Corel Word Processing
`.wad`	application/x-doom	—
`.wasm`	application/wasm	Web Assembly
`.wax`	audio/x-ms-wax	—
`.wbxml`	application/vnd.wap.wbxml	—
`.webm`	video/webm	—
`.wk1`	application/vnd.lotus-1-2-3	Lotus 1-2-3
`.wk2`	application/vnd.lotus-1-2-3	Lotus 1-2-3
`.wk3`	application/vnd.lotus-1-2-3	Lotus 1-2-3
`.wk4`	application/vnd.lotus-1-2-3	Lotus 1-2-3
`.wm`	video/x-ms-wm	—
`.wma`	audio/x-ms-wma	—
`.wmd`	application/x-ms-wmd	—
`.wmlc`	application/vnd.wap.wmlc	Compiled WML Document
`.wmlsc`	application/vnd.wap.wmlscriptc	Compiled WML Script
`.wmv`	video/x-ms-wmv	—
`.wmx`	video/x-ms-wmx	—
`.wp`	application/vnd.wordperfect	WordPerfect - Corel Word Processing
`.wp5`	application/vnd.wordperfect	WordPerfect - Corel Word Processing
`.wp6`	application/vnd.wordperfect	WordPerfect - Corel Word Processing
`.wp61`	application/vnd.wordperfect	WordPerfect - Corel Word Processing
`.wpd`	application/vnd.wordperfect	WordPerfect - Corel Word Processing
`.wpl`	application/vnd.ms-wpl	—
`.wpt`	application/vnd.wordperfect	WordPerfect - Corel Word Processing
`.wqd`	application/vnd.wqd	—
`.wri`	application/x-mswrite	—
`.wrl`	model/vrml	—
`.wtb`	application/vnd.webturbo	—
`.wvx`	video/x-ms-wvx	—
`.x32`	application/x-authorware-bin	—
`.x3d`	application/vnd.hzn-3d-crossword	—
`.x3f`	image/x-raw-sigma	Sigma raw image
`.xap`	application/x-silverlight-app	—
`.xar`	application/vnd.xara	—
`.xbap`	application/x-ms-xbap	—
`.xbd`	application/vnd.fujixerox.docuworks.binder	—
`.xdw`	application/vnd.fujixerox.docuworks	—
`.xfdl`	application/vnd.xfdl	—
`.xif`	image/vnd.xiff	—
`.xo`	application/vnd.olpc-sugar	—
`.xpi`	application/x-xpinstall	—
`.xpm`	image/x-xpixmap	—
`.xport`	application/x-sas-xport	SAS XPORT Transfer File
`.xpr`	application/vnd.is-xpr	—
`.xpt`	application/x-sas-xport	SAS XPORT Transfer File
`.xpw`	application/vnd.intercon.formnet	—
`.xpx`	application/vnd.intercon.formnet	—
`.xwd`	image/x-xwindowdump	X Windows Dump
`.xyz`	chemical/x-xyz	—
`.zir`	application/vnd.zul	—
`.zirz`	application/vnd.zul	—
`.zoo`	application/x-zoo	—
`.zst`	application/zstd	https://tools.ietf.org/id/draft-kucherawy-dispatch-zstd-01.html

what-to-do-next

If your format is on the parsed list, you're already covered. See the browsable format directory for the deep-dive guide and free in-browser tool for common ones. Or just call the API directly. If it's detect-only or missing entirely, tell us what you're working with. That's how .wpd, .mobi, .jp2, and .azw3 got caught and fixed on this exact page instead of staying overclaimed.

faq

Why does txtfetch say "1,683 detected" but only "615 parsed"?: Apache Tika's detector recognizes a media type from its bytes. It looks at magic numbers, container structure, or XML namespaces. This works independently of whether any parser can read that type's content. Detection just means Tika can NAME the file correctly; parsing means it can hand back text or metadata. tika-server-standard 3.3.1 detects 1,683 media types. It has a real parser, direct or via supertype fallback, behind 615 of them. The other 1,068 come back correctly typed and empty.
What happens if I send a detect-only file to the API?: You get the correctly identified content type and an extraction error, never a fabricated text dump and never metadata dressed up as extracted text. The lookup above says so explicitly for every detect-only type it knows about, including the exact media type Tika assigns it.
Why do some formats look supported on other pages but show up detect-only here?: Because this page checks the actual pinned build instead of assuming from the file extension. .wpd (plain WordPerfect, as opposed to its versioned variants), .mobi, and .jp2 all detect cleanly in tika-server-standard 3.3.1, but none has a parser behind it. .azw3 isn't a media type this Tika version recognizes at all. All four are called out honestly below instead of quietly staying on a "we handle this" list.
Does OCR change any of these verdicts?: For 6 raster image types (PNG, JPEG, GIF, BMP, TIFF, WebP), yes. The generator that built this data runs without Tesseract on PATH. It can only see Tika's fallback metadata-only image parsers. The Lambda has Tesseract installed. Tika prefers TesseractOCRParser for those exact types. In production, they get real OCR text, not just dimensions and EXIF tags. The lookup and the table both flag this wherever it applies.
How was this generated, and can I check it myself?: Dump.java (marketing/scripts/tika-coverage/) loads Tika's default config and walks every registered media type. It resolves each one to its concrete parser class. This follows Tika's own supertype fallback, the same lookup CompositeParser itself does. Because of that, a type like text/x-python correctly shows up parsed via TextAndCSVParser instead of falsely reading as unsupported. build-coverage.mjs downloads tika-server-standard 3.3.1 and the Corretto JDK pinned in terraform/lambda-layers/build/versions.env. It verifies both against the checksums pinned there. Then it runs the dump and writes the JSON this page reads. See docs/tika-coverage.md for the exact commands.
Why is this data committed instead of generated on every build?: Regenerating it needs a ~75MB jar and a JDK on the build machine. That's reasonable to run by hand when the Tika version bumps, not something to add to every CI run. Instead, a test asserts the committed data's tikaVersion matches versions.env, so a layer bump that isn't accompanied by regenerating this file fails the build.
1,683 media types is a lot of table rows. Why not one page per format?: That's a doorway-page pattern: hundreds of thin, templated pages targeting long-tail keywords. It would drag the whole domain's quality signal down. A single well-organized reference page can capture the same traffic just as well. This page is deliberately one deep resource with a real lookup tool, not 1,683 near-duplicates.

Stop parsing. Start shipping.

Create an account and get an API key in minutes. The free Hobby plan needs no card.

Get started →