Vibe Engines is free, interactive AI engineering & system design — runs in your browser. Pick a learning path
RAG Chunking Playground
Drop in any text and compare chunking strategies — fixed-size, recursive, by-sentence, by-paragraph — with overlap highlighted and an estimated token count per chunk. Stop guessing your chunk size; see exactly how your RAG pipeline will split a document.
Retrieval-augmented generation (RAG) grounds a language model in your own data.Before a model can retrieve a document, the document must be split into chunks and embedded.Chunk size is a balance.Large chunks preserve context but dilute relevance and burn context tokens at query time.
Small chunks are precise but can lose the surrounding meaning a passage depends on.Overlap repeats a little text across chunk boundaries.Without it, a sentence split across two chunks may become unretrievable for either one.
A typical starting point is a few hundred tokens per chunk with ten to twenty percent overlap.The right strategy depends on your content.Prose benefits from sentence or paragraph splitting; code or logs often suit fixed-size windows.Try a few here and watch how the chunks change.
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
sizecharacters. Each window startssize − overlapcharacters after the last, whereoverlap = ⌊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 pastsize. - 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:
- 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.
- Chunk 2 takes the next three sentences, 224 characters and 56 tokens; chunk 3 takes the last four, 280 characters and 70 tokens.
- The summary reads 3 chunks and 66 avg tokens/chunk.
| Strategy (defaults) | Chunks | Average tokens | What the boundaries look like |
|---|---|---|---|
| Recursive, 300 chars | 3 | 66 | Whole sentences, sizes 224 to 284 characters |
| Fixed, 300 chars, 15% | 3 | 74 | Windows start at 0, 255 and 510; cuts land mid-word, as in “Small chunk” and “urn context” |
| By sentence | 11 | 18 | From 6 tokens (“Chunk size is a balance.”) to 24 |
| By paragraph | 4 | 50 | One chunk per paragraph, 43 to 59 tokens |
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.
How it works
- Fixed: cut every N characters, with an overlap percentage.
- Recursive: pack whole sentences and paragraphs up to the size cap.
- By sentence / paragraph: split on natural language structure.
- Token counts are estimated (~4 chars/token), close enough to size chunks.
Frequently asked questions
What is chunking in RAG?
Chunking is splitting a source document into smaller pieces before embedding them for retrieval. Each chunk becomes one vector, and at query time the closest chunks are pasted into the prompt. Chunk size and boundaries directly affect retrieval quality: chunks that are too large dilute relevance and waste context tokens, while chunks that are too small lose the surrounding meaning a passage needs to be understood on its own.
What chunk size and overlap should I use?
A common starting point is a few hundred tokens per chunk with 10 to 20% overlap, but the right values depend on your content, your embedding model and the questions people ask. Short factual answers favor smaller chunks; questions that need a whole argument favor larger ones. Use this tool to see how your own text splits, then confirm the choice by measuring retrieval quality on real questions rather than by eye alone.
What is the difference between fixed and recursive chunking?
Fixed chunking cuts every N characters regardless of structure, so it can split a sentence or even a word in half. Recursive chunking prefers natural boundaries: in this tool it breaks the text at paragraph breaks and sentence ends, then packs whole sentences into each chunk until adding the next one would pass the size limit. Chunks stay readable, but their sizes vary, and a single sentence longer than the limit becomes an oversized chunk.
Why does overlap between chunks matter?
Overlap repeats a little text at the boundary of adjacent chunks, so a fact that straddles a split still appears whole in at least one of them. Without it, a sentence cut in half can become unretrievable from either side. The cost is duplication: 15% overlap stores and embeds roughly 15% more text. In this tool overlap applies to fixed-size chunking, which is where blind cuts make it most necessary.
How are tokens estimated?
The tool divides each chunk’s trimmed character count by four and rounds, a common rule of thumb for English text with many tokenizers. It is close enough for sizing chunks, but real counts vary by model and language: code, numbers and non-English text usually produce more tokens per character. If an embedding model has a hard input limit, check your largest chunks with that model’s own tokenizer before indexing.