Tutorial: Tune Your RAG Chunking Visually (Free Browser Tool, No Setup)

Chunking is the RAG step everyone copies from a tutorial ("size 1000, overlap 200") and never looks at again. In this walkthrough, you'll use a free browser tool to actually see your chunks, compare strategies, estimate costs, and export working splitter code.

What you'll need: a browser and a sample document (Markdown or plain text works best). No install, no signup.

Tool: RAG Chunking Simulator & Visualizer

Per the site, text is processed locally in your browser instead of being sent to a chunking API. For confidential docs, still follow your organization's policies.

What you'll do

1. Load a document
2. Compare chunking strategies
3. Tune size and overlap
4. Inspect boundaries
5. Check diagnostics
6. Try parent-child chunking
7. Test retrieval with a keyword query
8. Estimate cost, storage, and context budget
9. Export code and chunks

Step 1: Load a document

Open the tool. Under Source document, you have three options:

• Use a built-in preset: RAG sample, Markdown sample, or Code sample
• Paste your own text
• Click Import .txt / .md

For this tutorial, start with the Markdown sample so heading-aware strategies have something to work with. A live counter shows characters, words, and estimated tokens as you type.

Step 2: Pick and compare strategies

In Compare chunking strategies, select several at once. The tool supports eight:

Strategy	Best for
Fixed-size	A simple baseline
Recursive character	General text (paragraph → newline → space fallback)
Sentence-aware	Avoiding mid-sentence cuts
Paragraph-aware	Keeping related sentences together
Markdown-aware	Docs with headings and structure
Heading-based	Splitting by section
Regex-based	Custom formats (you supply the pattern)
Word-based	Word-count limits instead of characters

Select Fixed-size, Recursive, and Markdown-aware for now.

The benchmark table then shows, per strategy: chunk count, average size, size variance, overlap characters, and estimated cost. Click any row to make it the active strategy in the visualizer below.

What to look for: two strategies can produce the same chunk count with very different size variance. High variance usually means some chunks are tiny and others are huge.

Step 3: Tune size and overlap

Under Chunk parameters, adjust:

• Chunk size
• Boundary overlap
• Measurement mode: Characters, Words, or Estimated tokens

Pick the unit deliberately. A character limit doesn't guarantee a chunk fits your model's token limit. If you choose estimated tokens, set Chars / token (the token counting mode also offers whitespace and word+punctuation counts).

Try this experiment:

1. Set overlap to 0 and note the chunk count and overlap chars.
2. Raise overlap gradually.
3. Watch the benchmark table: more overlap means more duplicated text, which means more tokens to embed and store.

The goal is the smallest overlap that still keeps context intact across boundaries. There's no universal number, so test on your own documents.

Step 4: Inspect boundaries visually

Scroll to the source boundary map. Alternating colors mark odd and even chunks, and shared overlap regions are highlighted separately.

Then:

• Use Prev / Next or the slider to scrub through chunks one at a time
• Click a block on the minimap ribbon to jump to that span
• Open the chunk preview inspector to read the actual content and its source offsets

Ask yourself at each boundary:

• Did a sentence get cut in half?
• Is a heading separated from its content?
• Is a code block or list broken apart?

If yes, switch strategy or adjust size and re-check.

Step 5: Read the diagnostics

The Chunk-size distribution & diagnostics panel gives you a 6-bucket histogram plus counts for:

• Tiny chunks (configurable Tiny threshold)
• Oversized chunks
• Boundary alerts
• Near duplicates

These are review prompts, not a verified quality score. The page itself labels the context-preservation heuristic as "not a validated retrieval-quality score." Use them to know where to look, then judge by reading the chunks.

Step 6: Try parent-child chunking

If small chunks match well but lack context, try Parent-child hierarchy chunking:

1. Set a Child size (small, for precise matching)
2. Set a Parent size (larger, for context)
3. Enter a query to see which child chunks rank and which parent context they map to

This models small-to-large retrieval: match on the child, return the parent. You can export the structure with Export parent-child JSON.

Step 7: Test with the keyword retrieval simulator

In Keyword retrieval simulator, enter a query you expect real users to ask and set Top K.

This is a lexical baseline, not an embedding search, so it won't predict your vector store's results. It's still handy for a quick sanity check: does the chunk that should answer the question rank near the top, or did a boundary scatter the relevant terms?

If your relevant text keeps landing in the wrong chunk, revisit Steps 3 and 4.

Step 8: Estimate cost, storage, and context budget

Three panels help with planning:

Embedding cost. Enter your provider's Price / 1M tok ($) and compare strategies in the benchmark table. Treat it as a relative comparison, not an invoice. Token counts are estimated from a chars-per-token ratio.

Index storage. Set vector dimensions, bytes per dimension (float32 / float16 / int8), and metadata bytes per chunk. The tool reports raw vector payload, metadata payload, and an estimated total. Real vector databases add their own overhead.

Context-window budget. Set a context budget and a reserve for prompt and answer. The tool greedily packs chunks to show how many fit. You can export the selected context.

Step 9: Export code and chunks

Once you've settled on settings, open the Framework configuration generator:

1. Choose LangChain (Python) or LlamaIndex (Python)
2. Review the generated code (synced to your current sliders)
3. Copy code, Download Python example, or Download config

For a recursive strategy, the LangChain output will look something like this (exact output depends on your settings):

from langchain_text_splitters import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,
    chunk_overlap=100,
    separators=["\n\n", "\n", " ", ""],
)

chunks = splitter.split_text(text)

To export the chunks themselves, use JSON, JSONL, CSV, or TXT. Before exporting, fill in Chunk attribution metadata (source ID, page, section, plus an optional JSON object) so every record carries its origin.

Heads-up on offsets: they're JavaScript UTF-16 code units, not UTF-8 byte offsets. Convert them if your pipeline expects bytes.

Step 10 (optional): Save and share your experiment

Under Experiment history & state sharing, name and save a snapshot in your browser, or use Copy share settings to generate a URL-hash link. Teammates open it and see your exact configuration.

Limitations to keep in mind

• Token counts and costs are estimates. Validate with your embedding model's real tokenizer before production.
• The keyword simulator is lexical, not semantic.
• Good-looking chunks don't guarantee good answers. Evaluate with real queries and measure retrieval relevance and answer quality in your actual pipeline.

Wrap-up

You've now loaded a document, compared strategies, tuned overlap, inspected boundaries, checked diagnostics, tried parent-child retrieval, estimated costs, and exported working code. Total setup time: zero.

Try it on your own docs: aabitech.com/tools/rag-chunking-simulator

Which strategy and chunk size worked best for your content? Share your findings in the comments. 👇