RAG Text Chunker (split for Embeddings)
Divide long-form text into chunks optimized for Embedding / RAG ingestion. Supports 4 strategies: fixed character count, fixed token count, paragraph-based, and Markdown heading-based chunking; includes overlap adjustment, chunk visualization, and JSON / JSONL / Markdown export options.
📖 Where people get stuck
Split a long document into units suited to an embedding model. Everything runs in the browser and no text is sent anywhere. When retrieval quality in a RAG system disappoints, the chunking is usually to blame rather than the embedding model — the answer got cut across two chunks, or a heading ended up separated from the text it introduced, and the context went with it.
| Case | What happens | What to do |
|---|---|---|
| Choosing a chunk size by feel | Too small and the answer will not fit in one chunk; too large and several topics share a chunk and the vector blurs. An embedding represents the average direction of its text, so the more unrelated material you mix in, the more the vector ends up vaguely similar to every question and decisively similar to none. | Start at 512–1,024 tokens with 10–20 % overlap, then actually count how long a typical answer is in your corpus. If answers are two or three sentences, as in an FAQ, 256 is plenty; if an answer is an entire procedure section, even 1,024 is short. Getting a feel for the characters-to-tokens ratio with the token counter makes the decision concrete. |
| Cutting purely by character count | A fixed-length cut lands in the middle of a sentence, a table, or a code block. In procedural or reference material especially, the moment a table header is separated from its rows, the chunk no longer says what the table is about. It may still match the query, but by the time it reaches the model the meaning is unrecoverable. | Respect structural boundaries first. For Markdown, split on headings (##), then on paragraphs if a section is still too long, then on sentences. On top of that, prepend a breadcrumb — document title, chapter, section — to every chunk. Accuracy improves markedly, because each chunk now states what it is about even when read alone. |
| Swapping the embedding model when recall is bad | What matters before the choice of model is the vocabulary gap between question and document. A user asks why they cannot log in; the document is headed handling authentication errors. The two are semantically close, but the vectors do not come as near as you would hope. And queries that hinge on an exact string — a product code, a proper noun — are precisely where vector search is weakest. | Go hybrid: run keyword search such as BM25 alongside vector search and fuse the rankings, for example with reciprocal rank fusion. The keyword side reliably catches product codes and names; the vector side catches paraphrase. If that is still not enough, have an LLM generate three questions each chunk can answer and embed those alongside it. Estimate the bill first with the embedding cost calculator. |
Chunking is not a setting you decide once and leave alone. Log the questions people actually ask, look at the ones that failed, and separate two causes: the right chunk never made it into the top results, or it did but the information was cut off partway. The first is a retrieval problem, the second a granularity problem. Conflate them and no amount of tuning will help.
📖 How to Use
-
1
Paste textPDF extracts, Markdown docs, articles
-
2
Pick strategy + tune sizechars / tokens / paragraphs / headings — match your embedding model context
-
3
Export JSON / JSONLchunks array + metadata for embedding pipeline
❓ Frequently Asked Questions
Recommended chunk size?
How much overlap?
Why heading strategy?
🐛 Found a bug or issue with this tool?
Free to use, no signup. Even just the steps to reproduce are helpful. Reports go directly to the operator and help us fix issues.
Thanks for your report!
Your report has been delivered to the operator and will be used to improve the tool.