What the RAG Chunking Simulator does
This simulator splits a document into chunks the way a retrieval-augmented generation (RAG) pipeline would - fixed windows, sentences, paragraphs or recursive splitting - and shows you exactly where every boundary falls, how big each chunk is, and how much text overlap repeats, before you spend anything on embeddings.
Chunking decides what your retriever can find. A chunk that cuts a refund policy in half, or a heading stranded on its own, can make the right answer unretrievable no matter how good the embedding model is. Seeing the boundaries on your own documents is the quickest way to pick sensible settings. The splitting happens in your browser; the document is not uploaded.
How to use it
- Paste a representative document, drop a .txt or .md file, or load an example.
- Choose a strategy. Recursive is the usual default; sentence and paragraph keep natural units whole; fixed gives equal windows regardless of meaning.
- Set the chunk size and the overlap, in estimated tokens or in characters. The results update as you type.
- Read the stats and the size histogram, then scroll through the boundary view: shaded bands are chunks, accent-coloured text appears in two chunks because of overlap.
- Download the chunks as JSONL (one object per chunk with its offsets) or CSV to feed a test index, or copy the settings into your pipeline config.
Reading the results
A tight histogram close to your target size means the strategy found boundaries near the limit. A long tail of small chunks usually means headings or list items are becoming chunks on their own - they embed with almost no meaning and can crowd better matches out of the top results.
Overlap repeats the end of one chunk at the start of the next so that a fact near a boundary is whole in at least one of them. The cost is storage and embedding spend: the repeated share is shown as a percentage of the document.
Offsets are positions in the original text, so each exported chunk can be traced back to the exact place it came from - useful for citations and for highlighting the source passage in your app.
Worked example: a help-centre article at 60 estimated tokens
The help-centre example is 1,074 characters, about 269 tokens by the characters / 4 estimate. At 200 tokens with 30 overlap, recursive splitting makes just 2 chunks, because the whole article barely exceeds one chunk.
Drop the size to 60 tokens with 10 overlap. Recursive splitting gives 7 chunks between 3 and 60 tokens. The 3-token chunk is the heading "## Refunds" on its own, and the heading "## How to start a return" sits at the end of chunk 1 and again at the start of chunk 2 because of the overlap - a typical sign that the size is too small for this document's sections.
Fixed windows at the same settings give 6 chunks, five of exactly 60 tokens and a last one of 19, but chunk 2 begins mid-sentence with "nd gift cards" and 195 characters are repeated by overlap. Paragraph splitting gives 6 chunks with no overlap and no broken sentences. For this kind of document, a larger size with paragraph or recursive splitting is the better starting point.
Formulas and scoring rules
- Estimated tokens
tokens = ceil(characters / 4)A rule of thumb for English text. Characters are Unicode code points, so an emoji counts once and is never split.- Fixed windows
start(n) = n x (size - overlap); end = start + sizeThe last window is whatever remains.- Overlap share
repeated = sum of (end of chunk n - start of chunk n+1) where positive; share = repeated / document length- Spread
sd = sqrt( sum (size_i - mean)^2 / n )Population standard deviation of chunk sizes.
How each strategy decides where to cut
Fixed takes windows of exactly the chosen size, stepping forward by size minus overlap. It ignores meaning completely, which makes sizes predictable and boundaries arbitrary.
Sentence and paragraph find natural units first - sentence-ending punctuation (including Chinese and Arabic marks, and skipping abbreviations like Dr. and decimals like 3.50) or blank lines - and pack whole units into each chunk until the next one would not fit. A unit longer than the size is cut into fixed windows.
Recursive follows the approach of LangChain's RecursiveCharacterTextSplitter: split on blank lines; if a piece is still too big, split it on line breaks, then on sentence ends, then on spaces, and only as a last resort between characters. Pieces are then packed up to the size. Overlap for the unit strategies is made of whole units from the end of the previous chunk, so it never starts mid-word.
Choosing a size
There is no universal best size. Small chunks retrieve precisely but lose context; large chunks keep context but dilute the embedding and use more of the model's context window per result. Many teams start between 200 and 800 tokens with 10 to 20 percent overlap and then measure retrieval quality on real questions. This tool shows the shape of the split; only an evaluation on your questions shows which shape answers them best.
Limitations: what the result does not prove
- Token counts are estimates. Your embedding model's tokenizer will count differently, especially for code, numbers and non-Latin scripts; confirm limits with the model's own tokenizer.
- It does not embed anything, so it cannot tell you which chunks will be retrieved for a question - only where the boundaries are.
- Semantic chunking (splitting where the embedding of the text changes) and layout-aware splitting of PDFs, tables and HTML are not simulated.
- Sentence detection is rule-based and will occasionally split after an abbreviation it does not know.
Privacy: where your data goes
Everything you paste, type or drop is processed in this browser tab. It is not uploaded, logged, stored or sent to analytics. Session recording and tag-manager scripts are switched off on this page.
Standards and sources
- LangChain - RecursiveCharacterTextSplitter
- OpenAI - What are tokens and how to count them
- Anthropic - Contextual retrieval
Frequently asked questions
What chunk size should I use for RAG?
Start with 200 to 800 tokens and 10 to 20 percent overlap, look at the boundaries here on your own documents, then measure retrieval on real questions. FAQ-style content suits small chunks; long explanatory documents usually need larger ones so each chunk carries enough context.
How much chunk overlap is enough?
Enough that a sentence or fact near a boundary appears whole in at least one chunk - often one or two sentences, or 10 to 20 percent of the size. More overlap costs storage and embedding spend for text you already have, and can return near-duplicate results.
What is recursive character text splitting?
It splits on the largest natural separator first - blank lines - and only splits a piece further, on line breaks, then sentence ends, then spaces, if it is still too big. The result keeps paragraphs and sentences whole wherever the size allows.
Why do I get tiny chunks?
Usually a heading, a short list item or a one-line paragraph ends up on its own because the next unit would not fit. Raise the size, switch to paragraph splitting, or merge headings with the text that follows them before chunking.
Are these token counts exact?
No. They use characters divided by four, a rule of thumb for English. Embedding models use their own tokenizers, and code or non-English text can produce many more tokens per character. Use the character unit when you need exact, reproducible limits.
What is in the JSONL export?
One JSON object per line with an id, the chunk text, its start and end offsets in the original document, the character count and the estimated token count - ready to load into a test index or an evaluation script.
Last reviewed by the A2Z.Tools team against the sources listed above.
