This article covers which file types 'Ask Lex' indexes, how special formats like ZIPs and images are handled, and what to expect from indexing performance.
TL;DR: Lex indexes most common document and image formats automatically. Knowing which file types are supported — and their limitations — helps you get the most out of your knowledge graph.
Supported File Types
Type | Extensions |
| |
Word |
|
Excel |
|
PowerPoint |
|
Plain text / scripts |
|
| |
Other |
|
Images |
|
📝 File extensions are case-insensitive — .PDF, .Pdf, and .pdf are all treated the same.
Unsupported File Types
These formats are skipped immediately and logged as unsupported.
Type | Extensions | Reason |
Executables / installers |
| Binary — no extractable text |
Outlook data archives |
| Opaque binary format |
Archives |
| Container formats — contents not unpacked |
Video / audio |
| No text content |
📝 ZIP files (.zip) are an exception — see below.
ZIP Files
.zip archives are indexed by extracting each entry individually. Here's how each entry type is handled:
Text files, PDFs, Word/Excel docs, XML, scripts — parsed via the standard text parser
Images — described and indexed via AWS Bedrock
Password-protected entries — skipped; all other entries in the same ZIP are still indexed
Nested archives (
.7z,.rar,.gz,.tarinside a ZIP) — skipped to avoid recursion
Images
Images ≤ 5 MB are described by AWS Bedrock and indexed as text.
Images > 5 MB are routed to AWS Textract instead. Textract supports .jpg, .jpeg, .png, and .tiff only — .gif, .bmp, and .jfif files over 5 MB are skipped with a warning.
Why image indexing has limited value for MSPs
The knowledge graph is built from named entities and relationships — device names, IP addresses, software versions, configurations, and how they connect. Images tend to contribute less than text documents for a few reasons:
Screenshots of UIs or dashboards — Bedrock describes what's on screen in general prose rather than extracting structured data like specific rules, IPs, or hostnames.
Photos of physical hardware — Rack photos and hardware closeups rarely contain configuration detail. Bedrock may identify a brand or model, but little else that's actionable.
Network diagrams exported as images — Some value here, but the same diagram saved as
.vsdxor embedded in a.docxor.pdfis significantly more useful, since those formats preserve the underlying structured data.
In practice, the highest-value content for GraphRAG is documentation: runbooks, configuration exports, vendor datasheets, tickets, and spreadsheet inventories. Images are indexed to avoid gaps, but they are not expected to be primary contributors to answer quality.
Password-Protected & Encrypted Files
ZIP entries — Password-protected entries are skipped; all other entries in the same ZIP are still indexed.
PDFs and Office documents — Password-protected files will fail to parse and be logged as failed.
Documents Without a File Attachment
Only system.document assets are indexed. If a document has no file attached but contains structured data fields — such as a title, notes, or description typed directly into the record — those fields are serialized to text and indexed automatically. No file upload is required.
Indexing Performance
Typical end-to-end pipeline times:
File type | p99 indexing time |
Plain text ( | ~11s |
Simple Word / Excel | ~15–30s |
PDF (text-based) | ~20–30s |
Complex Word ( | ~133s |
Excel ( | ~158s |
Images | ~15–103s |
PDF (scanned) | ~358s |
Why scanned PDFs are slow
Text-based PDFs — exported from Word, Excel, or a native PDF editor — have a real text layer and are indexed with no page limit.
Scanned PDFs (photos of paper documents with no text layer) take significantly longer:
Render — each page is rendered to a PNG image at 144 DPI.
Extract — each page image is sent to AWS Bedrock as a separate, sequential API call. Each call takes approximately 20 seconds.
Cap — only the first 25 pages are processed per invocation due to a 15-minute Lambda execution limit.
⚠️ Scanned documents longer than 25 pages are only partially indexed in the current release. For large scanned manuals, a text-based PDF exported from the source application is strongly recommended.
📝 Multi-pass support for longer scanned documents is planned for a future release.