RAG Chunking Playground

A retrieval pipeline can only retrieve what it stored, and it stores chunks. Split badly and no prompt recovers: cut mid-sentence and you embed half-thoughts; make chunks huge and each embedding becomes a blurry average. This tool shows exactly how four common strategies split your text, chunk by chunk, with sizes.

What it computes

• Fixed size: windows of size characters. Each window starts size − overlap characters after the last, where overlap = ⌊size × overlap% ⌋, and the last window ends at the end of the text.
• Recursive: the text is broken at blank lines and after every ., ! or ? followed by whitespace. Pieces are appended to a buffer, and the buffer becomes a chunk whenever the next piece would push it past size.
• By sentence: one chunk per run of text ending in sentence punctuation. Size is ignored.
• By paragraph: one chunk per block separated by a blank line. Size is ignored.

tokens(chunk) = max(1, round(trimmed characters / 4))
average       = round(sum of chunk tokens / number of chunks)

A worked example

The sample document is four paragraphs about chunking, 801 characters, estimated at 200 tokens. The default strategy is recursive with a 300-character limit:

1. The first paragraph’s two sentences fit, and so do the next two, ending “…at query time.” Adding the following sentence would pass 300 characters, so chunk 1 closes at 284 characters, 71 tokens.
2. Chunk 2 takes the next three sentences, 224 characters and 56 tokens; chunk 3 takes the last four, 280 characters and 70 tokens.
3. The summary reads 3 chunks and 66 avg tokens/chunk.

Fixed windows overlap by 45 characters, so the phrase “context tokens at query time. Small chunk” appears in two chunks. That duplication is the price of never losing a sentence at a cut.

Assumptions and limits

• Characters, not tokens. Sizes are set in characters and tokens are a four-characters-per-token estimate.
• Simple sentence detection. Abbreviations, decimals and ellipses end a “sentence” early, and text without punctuation never splits.
• No word-level fallback. Recursive mode does not split a sentence longer than the limit, and it joins sentences without the whitespace between them, so its character counts run slightly low.
• Overlap only in fixed mode. The other strategies never repeat text.
• No structure awareness. Headings, tables, lists and code are treated as plain text.

How to use the result

• Read the chunks, not just the counts. Each one should make sense alone; if it needs its neighbor to be understood, grow the size or split on structure.
• Start near a few hundred tokens with 10 to 20% overlap, then tune against retrieval metrics on real questions.
• Match strategy to content. Sentence or paragraph boundaries suit prose; fixed windows suit logs and long unpunctuated text.
• Keep provenance. Store each chunk’s source and position so answers can cite it.

When to use it, and when not

Use it to pick a starting size and strategy on a real sample of your documents, to show a team why fixed windows cut words in half, and to catch oversized chunks before an embedding model truncates them. Paste a typical page, a long one and an awkward one, such as a document full of lists or code, and read every chunk.

Look elsewhere for documents whose structure carries meaning: Markdown with headings, HTML, tables, source code, PDFs with columns. A splitter that understands that structure keeps a table row with its header and a function in one piece. And no splitter, this one included, tells you whether retrieval works. Only an evaluation on real questions, checking that the right chunk comes back, settles the size.

Trade-offs and limits

Overlap costs more than its percentage. Windows advance by size − overlap, so on a long document stored text grows by 1 / (1 − overlap%) − 1: 11% extra at 10%, 18% at 15%, 25% at 20% and double at 50%. On the short sample the last window is cut short, so 15% overlap stores 891 characters for 801, 11% extra.

Chunk size sets three costs at once. For an illustrative corpus of 10 million characters, with 1,536-dimension float32 vectors at 6,144 bytes each:

Small chunks mean more vectors and a sharper match for each, but every hit brings less surrounding text. Large chunks are cheaper to index and give the model more per hit, at the price of embeddings that average several topics together.

Recursive mode sits between: whole sentences, no repeats, uneven sizes. On the sample its three chunks run 224 to 284 characters against a 300 limit, so on average they use 88% of it; a chunk is closed early whenever the next sentence would not fit.

Common mistakes

• Sizing in characters against a token limit. Four characters per token is an English-prose average. Code, URLs, numbers and many other languages produce more tokens per character, so a chunk that looks safe can pass an embedding model’s input limit and be silently truncated.
• Chunks that lose their subject. A chunk that begins “It also supports streaming” no longer says what “it” is, so its embedding cannot match a question that names the product. Prepend the document title or section heading to each chunk before embedding.
• Heavy overlap as a cure for bad boundaries. 50% overlap doubles storage and embedding cost and fills the top results with near-copies of one passage. Split on sentences or structure instead.
• Tiny tail chunks. Fixed windows end wherever the text does, so the last chunk can be a few words that mostly repeat the one before. Merge a final chunk below a minimum size into its neighbor.
• Changing the splitter without re-indexing. Chunks from two strategies, or two embedding models, in one index give scores that do not compare. Re-chunk and re-embed the whole corpus together.

Check yourself