Chunk Overlap in RAG: What It Is and How Much You Need

Chunk overlap repeats the tail of each chunk at the start of the next one, so a fact that spans a boundary isn't split in half and lost to retrieval.

A little overlap helps; too much wastes tokens and storage. A common range is 10–20% of chunk size — but the right amount depends on how your information sits relative to your boundaries.

The problem overlap solves

When you split a document into chunks, some facts land right on a boundary — the setup in one chunk, the payoff in the next. Retrieve either chunk alone and the fact is incomplete. Overlap fixes this by repeating a slice of the end of each chunk at the beginning of the following one, so boundary-spanning information appears whole in at least one chunk.

How overlap works

If your chunk size is 600 characters and your overlap is 60, each chunk shares its last 60 characters with the next chunk's first 60. The chunks still advance through the document, but with a repeated seam between them. That seam is cheap insurance against splitting a key sentence exactly where it mattered.

chunk_size = 600
overlap    = 60          # ~10% of chunk size
step       = chunk_size - overlap   # advance 540 chars per chunk
# each chunk shares its last 60 chars with the next chunk's first 60

How much overlap?

More overlap means fewer facts get split, but also more repeated text — which costs more to embed, more to store, and can surface near-duplicate chunks at retrieval time. A common starting range is 10–20% of chunk size. Below that you risk splitting facts; well above it you're mostly paying to store the same text twice.

Overlap is insurance.
Buy enough to cover the seams, not more.

Free RAG Chunk Visualizer — see your chunks, token counts, and quality flags in the browser. Try it free.

Structure-aware chunking needs less

Overlap matters most with fixed-size chunking, where cuts fall arbitrarily. Structure-aware chunking already splits on natural boundaries, so fewer facts get cut and less overlap is needed. The two knobs interact: the better your boundaries, the less overlap you have to buy.

See the overlap and its cost

Overlap is easiest to reason about when you can see it. The RAG Chunk Visualizer marks the overlapping region between chunks and counts the overlap tokens, so you can see exactly how much repeated text a given setting produces — and what it adds to your indexing cost — before you commit. Overlap control is part of the Full Edition.

---

Go further: the Full Edition adds overlap control, cost-model presets, top-k modelling, strategy comparison, JSON export, and vector-DB record preview. Get the Full Edition. Built as a companion to RAG: The Complete Guide.

FAQ

What is chunk overlap in RAG?

Repeating the tail of each chunk at the start of the next one, so a fact that spans a chunk boundary appears whole in at least one chunk instead of being split in half and lost to retrieval.

How much chunk overlap should I use?

A common range is 10–20% of chunk size. Below that, boundary-spanning facts risk getting split; well above it, you're mostly paying to store and embed the same text twice. The right amount depends on your documents.

Does chunk overlap increase cost?

Yes. Overlapping text is embedded and stored more than once, so more overlap means higher indexing cost and storage, and it can surface near-duplicate chunks at retrieval time. It's a trade-off against losing boundary-spanning facts.

Do I need overlap with structure-aware chunking?

Less than with fixed-size. Structure-aware chunking splits on natural boundaries, so fewer facts get cut and less overlap is needed. The better your boundaries, the less overlap you have to buy.

How do I see how much overlap I'm using?

A chunk visualizer can mark the overlapping region between chunks and count overlap tokens, showing exactly how much repeated text a setting produces and what it adds to indexing cost before you commit.