RAG Chunking Calculator
Inputs
| Document Tokens | 8,000 |
|---|---|
| Chunk Size | 512 |
| Chunk Overlap | 64 |
RAG Chunking Calculator
Work out how many overlapping chunks a document splits into for retrieval-augmented generation, and how many tokens that sends to the embedding model.
Inputs
Document
Chunking
Results
Enter a value to see results.
Details
RAG chunking
Retrieval-augmented generation (RAG) answers a question by first searching a collection of documents for relevant passages and then feeding those passages to a language model. Because a whole document is usually too long to embed and retrieve as a single unit, each document is first split into smaller pieces called chunks. Chunking is the step that decides how those pieces are cut, and it shapes both retrieval quality and embedding cost. This calculator reports how many chunks a document of a given length produces and how many tokens that sends to the embedding model.
How chunking works
A splitter slides a fixed-size window across the document. The window is
chunk_size tokens wide, and after emitting each chunk it advances by a
stride rather than by the full width, so that consecutive chunks share a band
of chunk_overlap tokens. The overlap exists so that a fact straddling a
chunk boundary still appears whole in at least one chunk — without it, a
sentence cut in two could be retrievable from neither half.
The stride is the chunk size minus the overlap:
s=c−oA document of tokens is covered once the first chunk has consumed tokens of head start and the remaining tokens have been walked in steps of , which takes
n=⌈sT−o⌉chunks. The ceiling accounts for the final, possibly short, window. Each of the chunks is embedded at its full size, so the total tokens sent to the embedding model are
Temb=n⋅cBecause every chunk after the first repeats tokens, is larger than the original whenever the overlap is non-zero.
Worked example
Take a document of 8,000 tokens, split with a chunk size of 512 and an overlap of 64. The window advances by
s=512−64=448 tokensand the number of chunks is
n=⌈4488000−64⌉=⌈4487936⌉=⌈17.71⌉=18Embedding all 18 chunks at full size sends
Temb=18×512=9216 tokensto the embedding model. The overlap has inflated the embedded volume from 8,000 to 9,216 tokens — about 15 percent more — which is the price paid for keeping boundary-spanning passages intact. That ratio is close to the chunk size divided by the stride, .
Notes and variations
Real splitters rarely cut on exact token boundaries. Most respect sentence or paragraph breaks, so chunks vary in length and the count differs slightly from the uniform-window estimate here. Recursive and semantic splitters adjust boundaries to natural structure, trading uniformity for coherence. The overlap fraction is the main lever on embedded volume: a 50 percent overlap roughly doubles the tokens embedded, while a zero overlap embeds exactly the document length but risks splitting facts.
Application
The chunk count drives downstream sizing. Each chunk becomes one vector, so it feeds directly into the index footprint computed by Vector Database Size Calculator, and the embedded-token total sets the one-time embedding spend estimated by Embedding Cost Calculator. Tuning chunk size and overlap therefore trades retrieval precision against both storage and embedding cost at once.
Frequently Asked Questions (FAQ)
Why add overlap between chunks?
A hard split can cut a sentence, table row, or fact in half, leaving neither chunk with the complete information. Overlap repeats the last part of one chunk at the start of the next, so a passage that straddles a boundary still appears intact in at least one chunk. The trade-off is that the repeated tokens are embedded more than once, raising the embedding cost and adding near-duplicate entries to the index.
What chunk size should I use?
There is no universal best value; it depends on the content and the retrieval task. Smaller chunks, around 256 to 512 tokens, isolate a single idea per chunk and retrieve precisely, which suits fact lookup. Larger chunks, 1,000 tokens or more, preserve more surrounding context, which helps summarization and reasoning questions. A common starting point is 512 tokens with a 10 to 20 percent overlap, then adjust based on retrieval quality.
Why are more tokens embedded than the document contains?
Every chunk after the first repeats the overlap region of the previous chunk, so those tokens are embedded twice. The total embedded count is the number of chunks times the chunk size, which is larger than the raw document length whenever there is any overlap. The ratio of embedded tokens to document tokens is roughly the chunk size divided by the stride, so a heavy overlap can inflate embedding volume well above the original document size.
Disclaimer
Token counts depend on the model tokenizer and on how the splitter handles sentence and paragraph boundaries; real pipelines rarely produce perfectly uniform chunks. Treat these figures as planning estimates and verify exact counts and embedding spend with your own tooling.