Resources · n8n integration

n8n Recursive Character Text Splitter nodeConfigure Recursive Character Text Splitter in n8n.

Chunking decides how good your retrieval gets. The n8n Recursive Character Text Splitter node splits text recursively, keeping paragraphs together, then sentences, then words, as long as the chunk size allows. Three fields to set, one output port to plug, and it never runs on its own.

Try the Recursive Character Text Splitter node on n8nSee the 3 parameters

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n Recursive Character Text Splitter node do?

It cuts the text a loader hands it into chunks of the size you pick, and it cuts where the text already breaks. Paragraphs stay whole while they fit, then sentences, then words. A chunk only breaks mid-word when nothing else works, which is why this splitter is the one n8n recommends for most use cases.

Start with a knowledge base. A Default Data Loader reads the documents your workflow collected, this splitter cuts each one, and the chunks are embedded and stored so that an AI Agent can answer questions over them later. The quality of those answers rides almost entirely on Chunk Size and Chunk Overlap: a chunk that stops in the middle of a definition retrieves badly, no matter how good the model behind it.

Second case, a long report nobody reads. A Summarization Chain cannot swallow a hundred pages in one call, so it works through the text piece by piece. The splitter is what produces those pieces, and Chunk Overlap is what keeps a sentence that straddles two of them from being amputated. The model behind the chain comes from a provider like OpenAI or Anthropic, and it is that provider, not the splitter, that bills the calls.

Third case, a watch pipeline. Articles arrive, get split, get stored, and a daily digest goes out through Gmail. Here the interesting field is Options: on technical content written in Markdown, Split Code makes the node cut on headings and code fences instead of guessing where a paragraph ends.

When is another approach better? A splitter that cuts every N characters flat is easier to reason about, because every chunk has exactly the same length, but it slices sentences without looking. Recursive splitting gives up that regularity to keep meaning together, and that trade is the right one often enough that n8n recommends it by default. The other alternative is no splitter at all: if each item already holds one short record, a row from Google Sheets or a single support ticket, cutting it adds nothing.

Limits, before you wire it. The node counts characters, not tokens, so a chunk size that fits one model's context window can overflow another's. It exposes three fields and a single option at version 1, nothing about metadata, headers or sentence counts. And it is a sub-node: without a root node in front of it, activating the workflow changes nothing at all.

Connections

What do you plug this splitter into?

n8n splits AI workflows in two, a root node that runs on the workflow items and sub-nodes wired to its ports; this one is a sub-node, so it only does something once a root node calls it.

Output (what it plugs into)

  • Text Splitterai_textSplitter
01Text SplitterThe node has no main input and a single port, Text Splitter. You drag from it to a root node that accepts a splitter, and that root node decides when to call it and what text to hand over.

The node has no main input and a single port, Text Splitter. You drag from it to a root node that accepts a splitter, and that root node decides when to call it and what text to hand over.

Key parameters

  • Optional: a root node takes one splitter on this port, and this one is a candidate for it rather than an obligation.
  • Default Data Loader: turns the documents of an item into text, then passes each document through the splitter before anything is embedded.
  • Summarization Chain: needs long text cut before it can summarize it in several passes.
Use cases
one splitter can serve a loader in an indexing workflow, while a second workflow keeps its own with a different Chunk Size for summaries.
Parameters

Which fields does the node expose?

The Recursive Character Text Splitter node has 3 parameters. For each one: the node as you configure it in n8n, what the parameter changes, and our field notes.

01

Chunk Size

chunkSize

What you see in n8n

Notes & use cases

This field sets how many characters land in one chunk. It is the ceiling, not the exact length: the splitter fills a chunk up to that number, then backs up to the closest natural break below it.

Key parameters

  • Chunk Size: a count of characters, not of words or tokens, so budget for the difference when you size it against a model's context window.
Use cases
on a help center where each answer stands alone, a small size keeps one answer per chunk. On a contract, a larger one holds a clause and its exceptions together, which is exactly what a reader asking about that clause needs back.
02

Chunk Overlap

chunkOverlap

What you see in n8n

Notes & use cases

Overlap repeats the tail of a chunk at the head of the next one. Without it, a sentence sitting on a boundary is cut in two and neither half carries the whole statement, which is how a search misses a passage that is actually in the document.

Key parameters

  • Chunk Overlap: a count of characters copied from the previous chunk; keep it well below Chunk Size, since the repeated text eats into the same budget.
Use cases
a procedure that runs across a page break stays readable, because the last steps show up again at the start of the following chunk.
03

Options

options

What you see in n8n

Notes & use cases

Options is an empty collection until you add something to it. It carries the one setting that changes where the node looks for its break points, and leaving it closed keeps the plain prose behavior.

Key parameters

  • Options: the collection itself, opened from Add Option; nothing inside it is filled in for you.
  • Split Code: pick a language such as python, markdown, html or java, and the node cuts along that syntax instead of paragraphs.
Use cases
indexing a repository, where a function should stay in one chunk with its signature.
Need help

Need help automating Recursive Character Text Splitter with n8n?

A person reads every message.

FAQ

Questions people ask before wiring it

01Is the n8n Recursive Character Text Splitter node free to use?
Yes. It belongs to the AI package shipped with n8n, so there is nothing to install and nothing extra to pay on the n8n side, on n8n Cloud as on a self-hosted instance under the Community Edition and its Sustainable Use license. A workflow behaves the same in both. The one bill that does exist comes from elsewhere: the provider of the chat or embedding model plugged into the root node charges its own API calls under its own terms, and n8n adds nothing on top. Splitting text costs you nothing by itself, since the work happens inside your instance before any call leaves it.
02What do you need to set up before it works?
Nothing to authenticate, which is unusual enough to be worth saying. This node has no credential and no Authentication selector, so there is no account to connect and no key to paste. The credential lives on the model sub-node wired to the same root node, and that is where the provider key belongs. What you do need is a root node in front of it: a Default Data Loader in an indexing flow, or a Summarization Chain. Drag from the Text Splitter port to that root node, set Chunk Size and Chunk Overlap, and the node is ready.
03What are the limits of this node?
It counts characters, not tokens. A size that fits comfortably inside one model's context window can therefore overflow another one, and nothing in the panel warns you about it. At version 1 the node exposes three fields, with a single option inside the collection, Split Code. No cutting on metadata. No header repeated on every chunk, no way to reason in sentences rather than characters. It never runs alone either: no main input, no execution without a root node calling it. Older workflows may still display an earlier version of the node with fewer options, so check the version in the panel before comparing what you see with what this page describes.
04What is the minimum to plug in, and which sub-node should you start with?
Start with a Default Data Loader as the root node. It is the shortest path to something that works: the loader takes the documents on the item, hands them to the splitter, and the chunks move on to be embedded and stored. Wire the Text Splitter port, set Chunk Size, set a smaller Chunk Overlap, leave Options closed. Then read a few chunks before going further, because most retrieval problems are visible right there. A Summarization Chain is the other root node that takes this splitter, and it is the one to pick when the goal is a summary rather than a searchable index.
05n8n or Make for a chunking workflow like this?
It depends on where your documents live and who is allowed to read them. n8n runs on your own servers through Docker or npm, or on n8n Cloud, with the same workflow either way, so sensitive documents can be split and embedded without leaving your infrastructure. Make is hosted only, with no self-hosting option, and bills per operation, which is a different fit when a single indexing run cuts a large document into many chunks. Both let you build the logic visually. Pick on hosting, data control and the cost model rather than on the node list, since the chunking step itself looks similar on both.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.

Same platform

Other docs you might need on this stack.

Browse all integrations