RAG chunking visualizer

See exactly how your documents get chunked before you embed them. Paste text, set chunk size and chunk overlap in tokens, switch between chunking strategies, and watch the chunk boundaries, token counts, and embedding cost update live — all in your browser, no signup.

Total tokens

1,800

Chunks

4

Avg tokens / chunk

498

One-time embedding cost

$0.00004

Chunk spans across the document

Alternating colors are consecutive chunks; the dark bands are overlap regions embedded in both neighbors.

Chunk 1

512 tokens

Driftdesk is a shared-inbox and help-center platform for support teams of two to two hundred. Every conversation — email, chat widget, or contact form — lands i…

Chunk 2

512 tokens

adds the chat widget, the full automation engine, reporting dashboards, and unlimited inboxes. Scale adds SAML single sign-on, the audit log, custom data reten…

Chunk 3

512 tokens

it enters a warning state visible in the queue, and when the target is missed, the breach is recorded on the conversation and in reporting. Targets pause autom…

Chunk 4

456 tokens

customer leaves a poor rating with a comment. Survey frequency is capped per customer so a person with five conversations in a week is only asked once. Everyt…

Token counts use the GPT tokenizer family; other models' tokenizers differ by roughly ±10–20%. Embedding cost is computed on embedded tokens — chunk tokens including overlap — so it grows as you raise the overlap.

What chunking is and why RAG needs it

Retrieval-augmented generation grounds a model's answer in your own documents instead of its training data. To do that, each document is split into smaller passages — chunks — that are embedded into vectors and stored in an index. At query time, the user's question is embedded too, the most similar chunks are retrieved, and those passages are pasted into the prompt as context. The model only ever sees the chunks that came back, so the chunk boundaries decide what information is available to answer with. Get the split wrong and the right fact never reaches the model, no matter how capable it is — chunking is where most RAG quality is won or lost.

Chunk size versus overlap

Chunk size sets the core trade-off. Too small and a passage is embedded without the context needed to make sense of it — a similarity match that retrieves half an answer. Too large and the embedding is smeared across several topics, which blurs retrieval, and every retrieved chunk eats more of the prompt budget you pay for on each query. Overlap softens the boundary problem: by repeating a slice of text between adjacent chunks, a sentence that sits astride a split still gets embedded whole in at least one chunk. The cost is redundancy — you embed and store extra tokens, and the same passage can be retrieved twice. Most pipelines settle around 256–512 tokens with 10–20% overlap and then tune against real queries rather than guessing up front.

Chunking strategies and when each fits

  • Fixed-size. Cut every N tokens regardless of content. Predictable and cheap, but it happily splits mid-sentence — which is exactly what overlap exists to patch.
  • Recursive / character. The common framework default: try paragraph, then sentence, then word boundaries before falling back to a raw character split. A good general-purpose starting point.
  • Sentence or paragraph. Pack whole sentences or paragraphs up to the token budget so every chunk reads as coherent prose — well suited to articles, policies, and help-center content.
  • Structure-aware.Respect the document's own sections — headings, markdown, list items — so a chunk maps to a logical unit. Ideal for technical documentation and reference material.
  • Semantic. Split where the topic actually shifts, using embeddings to detect the break. Can lift relevance on dense prose, at the cost of extra compute up front.

How to choose, and common mistakes

Start from the shape of your content: structured docs reward structure-aware or sentence chunking, flat prose does fine with recursive splitting, and only reach for semantic chunking when retrieval quality demands it. Then size chunks to fit both your embedding model's input limit and your retrieval budget — the number of chunks you can afford to send the model per query. The mistakes that hurt most are ignoring document structure and slicing across meaningful boundaries, using no overlap so ideas get severed at the split, making chunks so large that only one or two fit the prompt (or so large they exceed the embedding model and get silently truncated), and never re-tuning against the queries users actually ask. Because chunking is a one-time embedding cost while the retrieved context ships on every request, oversized chunks quietly inflate the recurring bill more than the embedding step ever will.

Frequently asked questions

What is chunking in RAG?
Chunking is splitting a document into smaller passages before you embed them for retrieval. In a RAG (retrieval-augmented generation) pipeline, each chunk is turned into a vector, stored in an index, and matched against the user's question by similarity. The chunks that come back are pasted into the model's prompt as context, so how you cut the document decides what the model actually gets to read when it answers.
What is a good chunk size?
There is no universal number, but most production pipelines land between 256 and 512 tokens, then tune against real queries. Smaller chunks (128–256 tokens) capture a single focused idea and match precisely; larger chunks (512–1,024 tokens) preserve surrounding context but dilute the embedding and spend more of your prompt budget per retrieved passage. Match the size to how self-contained your content is and to how many chunks you can afford to send the model per query.
What is chunk overlap?
Overlap repeats a slice of text — commonly 10–20% of the chunk size — at the boundary between neighbouring chunks. It hedges against the split landing in the middle of a sentence or idea: with overlap, the passage that answers the question gets embedded whole in at least one chunk instead of being severed across two. The cost is redundancy — you embed and store more tokens, and the same text can be retrieved twice.
Which chunking strategy is best?
It depends on the document. Fixed-size token chunking is simplest and most predictable but cuts mid-sentence. Sentence- or paragraph-aware chunking keeps passages readable and suits articles, policies, and documentation. Structure-aware chunking that respects headings or markdown works well for technical docs with clear sections. Semantic chunking splits where the topic shifts and can improve relevance on dense prose at the cost of extra compute. Start with recursive or sentence-aware chunking and only reach for semantic splitting if retrieval quality demands it.
How does chunk size affect retrieval quality and cost?
Chunk size trades precision against context. Small chunks give sharp similarity matches but may retrieve a passage stripped of the context needed to answer; large chunks keep context together but blur the embedding across topics and push more tokens into every prompt. Because chunking is a one-time embedding cost while the retrieved context is sent on every query, oversized chunks quietly inflate your recurring per-request bill far more than the embedding step.
Does chunk size need to match the embedding model?
Yes — every embedding model has a maximum input length, and text beyond it is silently truncated, so a chunk larger than the model's window loses its tail before it is ever vectorised. Keep chunks comfortably under that limit. Some models also produce noticeably better vectors for shorter, single-topic passages, which is another reason to avoid packing chunks to the maximum just because you can.
Is this RAG chunking visualizer free?
Yes — it runs entirely in your browser, needs no signup, and sends nothing to a server. Paste a document, adjust chunk size, overlap, and strategy, and the chunk boundaries, token counts, and embedding cost update live so you can see the effect of each setting before you commit to a pipeline.

Related tools: RAG cost calculator (embeddings + storage + generation), context window comparison (count tokens and check what fits), and the LLM API cost calculator (price the context you retrieve on every query).

More free tools

  • LLM price comparison — Live table of every model's API prices — sort, filter, and cost out your own request size.
  • LLM cost calculator — Estimate per-request, daily, and monthly spend from token counts and request volume.
  • RAG cost calculator — Full pipeline costs — embeddings, vector storage, and generation — from corpus size and query volume.
  • LLM context window comparison — Count the tokens in any text and check which models it fits, against live context windows.
  • Tool call & MCP schema builder — Build function-calling parameters once, copy valid JSON Schema for OpenAI, Anthropic, and MCP.
  • AI chatbot ROI calculator — Turn ticket volume, handle time, and deflection rate into monthly support savings and ROI.