Preview your RAG chunks before you index
Before you embed a document into a vector database, it pays to see how it will be cut up. This previewer takes any text, applies your chunk size, overlap and split strategy, and renders a color-coded view of every chunk — including the overlap region shared with the next chunk — so you can tune retrieval quality without spending a single embedding token.
Why chunking strategy matters for RAG quality
In a retrieval-augmented generation pipeline, the chunks you index are the atomic units of retrieval. A query retrieves the top-k most semantically similar chunks, and those chunks are what the language model sees as context. If your chunks are poorly formed — too long, too short, or cut across sentence boundaries — the retrieved context will be either too noisy or too sparse, and the model’s answer will suffer regardless of how good the LLM is.
Chunking is often the easiest lever to pull when RAG answers seem vague or miss key facts.
The three parameters
Chunk size controls how much text each chunk contains (measured in characters in this previewer). Smaller chunks (around 200–400 characters) retrieve very precisely but give the model less surrounding context. Larger chunks (1,000–2,000 characters) preserve more context per retrieval but may return long passages where only one sentence is actually relevant. Most practical RAG systems land in the 500–1,000 character range for prose.
Overlap repeats the tail of each chunk at the start of the next. A fact that straddles a boundary appears whole in at least one of the two adjacent chunks. Without overlap, a sentence cut exactly at a boundary may be split between two chunks and retrieved in neither. Typical overlap is 10–20% of chunk size; too much wastes embedding budget and dilutes the semantic signal.
Split strategy decides where the cuts land:
- Fixed character — simplest, but can cut mid-sentence. Works well for structured text (code, JSON, logs) where sentences are not the natural unit.
- Sentence boundary — packs sentences until the target size is reached, then cuts between sentences. Much cleaner for prose; rarely leaves a dangling half-sentence.
- Paragraph boundary — cuts only between paragraph breaks. Produces the most semantically coherent chunks but can create very uneven sizes if paragraphs vary widely in length.
What the color-coded preview shows
Each chunk is shown as a numbered card with its character count. The overlap region — the text shared with the next chunk — is highlighted in a contrasting colour so you can instantly see whether important content survives the boundary. If you see a key fact consistently landing in the overlap zone, try reducing chunk size slightly so it falls cleanly inside a single chunk.
Practical starting points
| Document type | Suggested chunk size | Overlap |
|---|---|---|
| General prose (articles, docs) | 800 characters | 120 characters |
| Technical documentation (code-heavy) | 500 characters | 80 characters |
| Long-form contracts or legal text | 1,200 characters | 150 characters |
| Structured data / logs | 400 characters | 0 |
Start with these, preview the output, run a few test queries against your retriever, and adjust. The right chunking strategy is always document-specific.
All chunking runs locally in your browser. Nothing you paste is uploaded, stored or logged.