RTF

Yes. Because RTF is a single plain-text file where formatting is expressed inline as backslash-prefixed control words and brace-delimited groups, a DAM can strip that markup with a simple parser instead of unzipping and parsing XML (DOCX) or reading an OLE Compound File (legacy DOC). The parser still needs to skip destination groups like fonttbl and colortbl and correctly decode uN Unicode escapes, so indexing quality depends on handling those cases, not on external libraries.

RTF has no container-level compression, so embedded images are hex-encoded — every byte becomes two ASCII hex characters — directly into the plain-text stream, roughly doubling the raw image data before any other overhead. DOCX instead stores images as separate binary files inside a ZIP archive, which compresses the surrounding XML and package structure even though JPEG/PNG image data itself is already compressed. For a DAM ingesting many image-heavy documents, that difference translates into meaningfully larger storage and transfer footprints for RTF.

No. Microsoft published the RTF 1.0 specification in 1987 and continued revising it for roughly two decades, ending with version 1.9.1 in 2008, released to support Office 2007 features. Since then Microsoft has issued no further updates to the specification itself. For a DAM, that stability is actually convenient: a parser built against 1.9.1 covers essentially all RTF files it will ever encounter, since the format's frozen feature set means no new control words or capabilities are being introduced.

Generally no. RTF's lack of container-level compression makes it inefficient for image-heavy documents, and Microsoft hasn't updated its specification since version 1.9.1 in 2008, unlike DOCX and ODT, which remain actively maintained standards with more efficient structured storage. RTF's strength is staying readable as plain text without specialized software, which suits it as an interchange or export target. A DAM should treat RTF as a compatibility option, reserving DOCX or ODT as the primary archival master for richly formatted documents.

RTF itself is not designed to execute macros, but historically RTF has been used as a vector for exploits embedding OLE objects, so untrusted RTF uploads should still be scanned by a DAM's security pipeline.

Mostly, but not perfectly. Core formatting like bold, italics, fonts, and paragraph alignment is handled consistently because it's central to the specification, but Microsoft controls RTF and has occasionally added control words that other vendors implement incompletely or not at all. RTF's design lets an application skip control words it doesn't recognize rather than error out, so unsupported formatting is typically dropped silently instead of breaking the file. A DAM generating RTF previews should verify rendering fidelity across whichever applications it relies on rather than assuming identical output.

Yes, and it's a common pattern precisely because RTF rendering can vary slightly across applications. Running RTF through a headless conversion engine — such as LibreOffice in server mode — at ingestion time produces one canonical, layout-locked PDF preview that renders identically for every user, regardless of which word processor created the original file or which application end users have installed. This also lets a DAM generate a stable thumbnail and reuse the same conversion pipeline it likely already applies to DOCX and ODT masters.

Because generating valid RTF only requires writing a single flat text stream of control words and braces — no ZIP archive or interdependent XML parts to assemble. DOCX, by contrast, requires bundling document.xml, styles, relationships, and content-type declarations into a well-formed ZIP package, which is meaningfully more implementation overhead for a system that just needs to emit formatted text. RTF has also existed since 1987, well before DOCX arrived with Office 2007, so many older systems built RTF export before DOCX existed and had little reason to add it afterward.