Choosing Document Types in the Knowledge Embed Node

A reference for the Document Type options available when you embed a document with the Knowledge node in Spojit, and how the Document Input field expects your file to be provided.

Overview

The Knowledge node has two modes: Embed and Query. In Embed mode, Spojit reads a file, splits it into searchable chunks, and stores those chunks in a collection so that later steps (or other workflows) can answer questions against the content. Before Spojit can do that, it needs to know how to read the file you are handing it. That is what the Document Type setting controls: it tells the node how to extract text from the raw bytes, whether that means parsing a spreadsheet, walking an HTML page, or running optical character recognition over a scanned image.

Picking the right Document Type is the difference between clean, well-structured chunks and a collection full of garbled text. The mental model is simple: the Document Type describes the format of the source, and the Document Input field carries the actual file (as a base64 reference) that matches that format. Get the pairing right and the rest of the Knowledge pipeline (chunking, embedding, and later querying) just works. This guide lists every supported Document Type, explains what each one expects, and covers how to feed the file in.

Supported Document Types

Open the Knowledge node, set Mode to Embed, and choose from the Document Type dropdown. The supported formats are:

PDF - text-based or scanned PDF documents such as invoices, contracts, and reports. For scanned PDFs that are pure images, prefer the Images via OCR option so the text is recognized rather than skipped.
Word - Microsoft Word documents (.doc, .docx), such as policies, proposals, and write-ups.
Excel - Microsoft Excel workbooks (.xls, .xlsx). Rows and cells are read into text so tabular content stays searchable.
PowerPoint - Microsoft PowerPoint decks (.ppt, .pptx). Slide text and notes are extracted.
CSV/TSV - delimited data files. Use this for exported records, catalogs, or any comma or tab separated table.
JSON - structured JSON data, for example an API response or an exported record set you want to make queryable.
XML - XML documents such as feeds or legacy system exports.
HTML - raw HTML markup. Spojit reads the readable text from the page structure.
Plain Text - unformatted .txt content. The simplest option when you already have clean text.
Markdown - Markdown documents (.md), such as docs and notes, with headings preserved as structure.
RTF - Rich Text Format documents.
Email EML/MSG - saved email files. Use this when you have an exported message file rather than live mail.
EPUB - EPUB e-books and long-form publications.
Images via OCR - image files (photos, screenshots, scans). Spojit runs optical character recognition to turn pixels into searchable text.
Web Page URL - a live web page. Instead of a file, you provide the page address and Spojit fetches and reads it.

How Document Input Works

For every Document Type except Web Page URL, the Document Input field expects a base64 reference to the file bytes, not a file path or a plain string. In practice you reference an upstream variable that already holds base64 content. Common sources include:

An email attachment fetched with the Attachment node in a Mailhook workflow: reference {{ attachment.content }} in Single mode.
A file downloaded from your FTP/SFTP connector with the download-file tool: reference the content field of that step, for example {{ sftp_result.data.content }}.
A file produced earlier in the run by another node that emits base64 content.

When you choose Web Page URL, the field changes meaning: provide the page URL (templated values are fine) instead of base64 bytes, and Spojit retrieves the page for you. Confirm the Document Type matches the actual bytes you are passing, because the node trusts your selection when it decides how to parse the input.

File Name, Collection, and Output

Alongside Document Type and Document Input, Embed mode has a few more fields worth knowing:

Collection - choose a persistent collection to keep the embedded content for later workflows, or Transient for a one-off embed that is queried later in the same run and then discarded. Transient is ideal for single-document extraction such as reading one invoice.
File Name - required for persistent collections (it overwrites any existing document with the same name) and not needed for Transient.
Embedding Model - optional. Whatever model a collection uses for Embed must also be used when you Query it, so leave this consistent across both modes for the same collection.
Output Variable - holds the chunk count and metadata after embedding, so a later step can confirm the document was processed.

Tips

Match the Document Type to what the bytes actually are, not just the original file extension. A .pdf that is really a scan of a paper invoice will read far better as Images via OCR than as PDF.
For invoice or document extraction on a single file, pair a Transient collection in Embed mode with a Query node later in the same run. You skip naming and storage entirely.
Ask Miraxa, the intelligent layer across your automation, for help wiring this up: for example, "Add a Knowledge node in Embed mode that reads {{ attachment.content }} as a PDF into a Transient collection." Miraxa can scaffold the node and you fine-tune the Document Type in the properties panel.
When embedding spreadsheets or delimited data, consider whether Excel or CSV/TSV best preserves your rows; very wide tables sometimes chunk more cleanly as CSV.

Common Pitfalls

Passing a plain text string into Document Input instead of base64. Every type except Web Page URL expects a base64 reference such as {{ attachment.content }}.
Selecting PDF for a scanned, image-only PDF. Text extraction returns little or nothing; use Images via OCR instead.
Using a different embedding model to Query than you used to Embed. A collection must Embed and Query with the same model or results will be poor.
Forgetting the File Name on a persistent collection. It is required there, and reusing a name overwrites the earlier document.