# Format examples

What the extended formats actually produce — real chunks from the engine for JSON, email, RTF, EPUB, notebooks, and OpenDocument.

The core formats (PDF, Word, PowerPoint, Excel, HTML, Markdown, TXT, CSV) are
covered throughout the docs. This page shows what the **extended** formats
produce — every example below is real output from the engine, not illustration.

  These formats route through the same `get_chunks` / `getChunks` API and the
  same [chunking modes](/docs/chunking-modes) and [output
  schema](/docs/output-schema) as everything else — you don't call anything
  special. Dispatch is by extension.

## Structured data — JSON / JSONL / NDJSON

Each record is rendered as a `key: value` block and emitted as a `bullet_list`
chunk; nested objects are indented. For **JSONL / NDJSON** you get **one chunk
per line**; for **JSON** you get one chunk per top-level array element (or the
whole document when it isn't an array).

```json
// one line of an NDJSON access log
{"agent":"Debian APT-HTTP/1.3","bytes":0,"remote_ip":"93.180.71.3","request":"GET /downloads/product_1 HTTP/1.1","response":304}
```

```text
// → one chunk, content_type "bullet_list"
agent: Debian APT-HTTP/1.3
bytes: 0
remote_ip: 93.180.71.3
request: GET /downloads/product_1 HTTP/1.1
response: 304
```

Metadata: `section_heading`, `section_level`, `document_metadata`. A 50k-line
log becomes 50k independently-embeddable chunks — pair it with
[streaming](/docs/streaming) to keep memory flat.

## Email — EML / MSG / MBOX

The message **subject becomes a `heading`** chunk and the body becomes
`plain_paragraph` chunk(s); the parser is encoding- and MIME-aware.

- **`.eml`** (MIME) and **`.msg`** (Outlook) — a single message → subject
  heading + body paragraphs.
- **`.mbox`** — a whole mailbox: a leading `Mailbox — N messages` heading, then
  the heading/paragraph/list/table chunks for every message in order.

```text
// .eml → 2 chunks
[heading]          This is a test message
[plain_paragraph]  <the message body…>
```

## Rich text — RTF

Headings and paragraphs, with correct decoding across the code pages RTF uses
(cp1252 / Shift-JIS / etc.). A Japanese `.rtf` titled タイトル yields a `heading`
chunk with the text intact — no mojibake.

## eBooks — EPUB

Chunked per spine item (reading order), with richer provenance than most
formats:

```text
// heading chunk from an EPUB
content: "Loomings"
metadata: {
  spine_index: 0,
  href: "OPS/content_001.xhtml",
  heading_path: null,
  page_number: null,
  ...
}
```

The `spine_index` and `href` tell you exactly which document in the book each
chunk came from — useful for deep-linking back into the source.

## Notebooks — IPYNB

Markdown cells become prose chunks; **code cells (and their outputs) become
`code_block` chunks**, fenced and kept whole.

```python
# a code cell
print("Hello World")
```

```text
// → content_type "code_block"
```print("Hello World")```
```

## OpenDocument — ODT / ODP / ODS

The OpenDocument family mirrors its OOXML counterpart exactly — same content
types, same metadata, same modes:

| Format | Behaves like | Emits |
| --- | --- | --- |
| **`.odt`** (text) | DOCX | `heading`, `plain_paragraph`, `table`, lists — the 7 document modes |
| **`.odp`** (presentation) | PPTX | `heading` (`Slide N`), `plain_paragraph`, `bullet_list` — one unit per slide |
| **`.ods`** (spreadsheet) | XLSX | `row_document` + the 6 spreadsheet modes, with `sheet_name` / `sheet_index` / `header_row` metadata |

  EPUB, IPYNB, EML/MBOX, and ODT/ODP also support `list_images=True`. ODS follows
  the XLSX family. See [Supported Formats](/docs/supported-formats#image-extraction).