★ Why your RAG returns garbage
RAG Chunking Visualizer
Paste a document and see exactly how fixed-size, recursive, sentence and markdown-aware chunking split it, with token counts and overlap highlighted.
- Runs in your browser
- No signup
1,181 characters · loading tokenizer… · nothing leaves your browser
Recursive · 300 chars · overlap 40
6 chunks
- 52
- avg tokens
- 29 / 71
- min / max
- 15
- overlap tokens
- $6.20
- embed 1M docs
Loading the tokenizer; token counts are estimates until it's ready.
one chunkoverlapClick a chunk to inspect it.
Chunk inspector
Click any coloured chunk in the document to see its text, size, heading path and what it shares with its neighbours.
Chunk sizes
Tokens per chunk (estimated). A tight cluster means predictable chunks.
Embedding cost assumes text-embedding-3-small at $0.02 per 1M tokens (OpenAI, checked 8 Nov 2026), counting overlap twice.
Export config
Copy-ready code for the strategy and settings above. Comments flag where a library differs.
from langchain_text_splitters import RecursiveCharacterTextSplitter
splitter = RecursiveCharacterTextSplitter(
chunk_size=300,
chunk_overlap=40,
separators=["\n\n", "\n", ". ", " ", ""],
keep_separator="start",
)
chunks = splitter.split_text(text)Your retrieval is only as good as your chunks.
I build RAG systems with evals, so you know when the answers get better or worse.
Why chunking matters
Retrieval doesn't search your documents; it searches your chunks. If a chunk cuts an answer in half, mixes two topics, or loses the heading that gives it meaning, the best embedding model in the world will still retrieve the wrong thing.
Chunking is the cheapest part of a RAG pipeline to change and one of the most common reasons for bad answers. Looking at the chunks, literally, is the fastest way to spot the problem.
Strategies compared
| Strategy | Splits on | Keeps structure | Best for |
|---|---|---|---|
| Fixed (chars) | Every N characters | No | Baselines, transcripts |
| Fixed (tokens) | Every N tokens | No | Strict token limits |
| Recursive | Paragraphs → lines → sentences → words | Partly | Most text documents |
| Sentence | Whole sentences, packed | Sentences | Prose, FAQs, policies |
| Markdown | Headings, then recursive | Sections + heading path | Docs and knowledge bases |
Choosing a size and overlap
Smaller chunks give precise matches but lose context. Larger chunks keep context but dilute the embedding, so a single relevant sentence gets averaged with everything around it. Most teams land somewhere around a paragraph, then tune.
Overlap protects answers that cross a boundary. A small overlap, often about a sentence, is usually enough. Large overlaps mostly add duplicate results and storage. The histogram above shows whether your chunks are evenly sized; a long tail of tiny chunks usually means headings or list items are being split off on their own.
Evaluate, don't guess
Pick twenty to fifty real questions with known answers. For each chunking setup, retrieve the top results and record whether the chunk containing the answer came back (hit rate) and how high it ranked. Change one thing at a time: strategy, size, overlap, or what you prepend to each chunk.
Then check end-to-end answers on the same questions, because a retrieved chunk can still be the wrong context for the model. Keep the set and rerun it whenever documents or settings change.
Questions engineers actually ask
What chunk size should I use for RAG?
Does my text leave the browser?
Which tokenizer does this use?
Is chunk overlap worth it?
Should I use semantic chunking?
More from the workbench
Fine print
Tools: on the house.
Engineer: by the hour.
The visualizer was free. Production RAG with evals is what I build.
I'm Himanshu, an AI and full-stack engineer. I build MVPs, AI agents and the growth plumbing around them for early-stage startups.