Retrieval-augmented generation (RAG) systems split source documents into chunks before embedding them, because embedding models have limited input length and retrieval quality degrades on very long passages.
Chunk size is a tradeoff. Smaller chunks retrieve more precisely but lose surrounding context; larger chunks preserve context but dilute the embedding vector and cost more per document at query time.
Overlap between adjacent chunks helps preserve context that would othe
Chunk 2311 chars · ~71 tokens
ry time.
Overlap between adjacent chunks helps preserve context that would otherwise be split across a chunk boundary, at the cost of re-embedding some text more than once.
A common starting point is 300-800 tokens per chunk with 10-20% overlap, then tuning based on retrieval evaluation against real queries.
Token counts are approximate. This runs entirely in your browser — very large documents (hundreds of thousands of characters) may render slowly since every chunk is displayed.
About the RAG Chunking Simulator
Chunk size and overlap are usually tuned by trial and error against retrieval quality, but it helps to first see what a strategy actually produces before running an evaluation. This tool applies fixed-character, approximate-token, or paragraph-based chunking to a pasted document and shows every resulting chunk with its token count.
Key Features
Three chunking strategies: fixed token count, fixed character count, and paragraph-aware splitting.
Configurable overlap between adjacent chunks.
Estimated embedding cost for the resulting chunk set — see the full Embedding Cost Calculator for corpus-wide projections.