RAG Chunk Splitter

▸ Token counts are estimates

This uses the ~4 chars/token heuristic, not a real BPE tokenizer. Good enough to size chunks and compare strategies — not for billing.

Source text

▸ 0 characters · ~0 tokens

Splitting strategy

▸ Packs whole sentences up to the target. Never cuts mid-sentence.

Measure chunk size in

▸ Switching converts your numbers at 4 characters per token.

Chunk size (tokens)

Overlap (tokens)

Embedding price ($ / 1M tokens)

▸ Varies by provider — roughly $0.02 to $0.13 per million tokens. Check the current price page.

Presets

▸ Chunk stats

0

chunks

Avg tokens: —
Min / max: —
Tokens embedded: —
Overlap tax: —
Embedding cost: —

Runs in your browser · nothing uploaded

The chunks.

overlap injected heading

Chunk size is the highest-leverage knob in RAG

Almost every RAG debugging session I get pulled into starts at the wrong end of the pipeline. Someone is swapping embedding models, bolting on a reranker, or arguing about hybrid search — and all of those operate on whatever the splitter already handed them. If the answer got cut in half at ingestion time, no amount of retrieval cleverness reassembles it.

Chunking happens once, upstream of everything, and every query pays for it forever. It is also the cheapest thing in the stack to change: adjust the splitter, re-embed, done. That is why it is the first thing I touch. My default for technical documentation is 512–1024 tokens with 10–15% overlap on real sentence or paragraph boundaries — then I measure retrieval recall against an actual question set instead of guessing twice.

Big chunks buy recall, small chunks buy precision

This is the trade you are actually making, and it is not a matter of taste. A large chunk is more likely to contain the answer somewhere inside it, but its embedding is an average of several topics, so it sits in a mushy region of vector space and matches vaguely. A small chunk embeds sharply and ranks well, but the answer may be split across two of them and only one will make the cut.

	Small (128–384)	Medium (512–1024)	Large (1536+)
Retrieval behaviour	Sharp match, high precision	Balanced	Broad match, high recall
Failure mode	Answer split across chunks	Occasional near-miss	Right chunk, buried answer
Context sent to the LLM	Fragmentary — needs top-10	Usually self-contained	Padded with irrelevant text
Index size and cost	Largest	Moderate	Smallest
Good fit	FAQs, product specs, logs	Docs, runbooks, guides	Contracts, papers, narrative

A useful rule: if your top-k results keep containing the right document but not the right sentence, chunks are too large. If they keep containing half the answer, chunks are too small. Those two symptoms point in opposite directions, so diagnose before you turn the dial.

Overlap is insurance, and you pay the premium on every chunk

Overlap exists for exactly one reason: a fixed-size window cuts blind, so you duplicate the seam to make sure a sentence straddling the cut survives in at least one chunk. That is a real problem and overlap is a real fix — for fixed-size splitting.

The moment your splitter respects sentence or paragraph boundaries, most of what overlap protects against has already been handled, and the premium starts looking expensive. Twenty percent overlap means 20% more vectors to store, 20% more index to search, and a top-k list where two of your five slots are near-duplicates of each other. The overlap tax figure in the stats panel is the number to watch: it is total tokens across all chunks minus the tokens in your source, i.e. exactly what you are embedding twice. The one-off embedding bill is usually pocket change; the permanent index bloat and the crowded top-k are what actually hurt.

Splitting mid-sentence wrecks the embedding, not just the text

An embedding model compresses the whole chunk into one vector. Feed it a fragment that ends "…therefore the migration must run before" and it produces a vector for a statement that has no meaning. That vector does not merely fail to retrieve — it pollutes the index, because a semantically incoherent chunk lands somewhere near everything and near nothing, and it will surface for queries it has no business answering.

The nasty part is that this survives eyeball review. The chunk still reads like text, so the ingestion pipeline looks fine right up until someone asks the question that needed the second half. Tables lose their header row and become unretrievable columns of numbers. Code blocks get separated from the paragraph that explains what they do. Both are invisible in a chunk dump and obvious in production.

Structure-aware splitting for markdown and code

Most documents already contain the boundaries you want, and you get them for free. Markdown headings mark topic changes better than any similarity threshold you could tune, which is why the heading-aware mode here starts a new chunk at every #, ##, or ### and keeps the heading attached to its body. When a section is still too big and has to spill into several chunks, the heading is re-injected at the top of each continuation chunk — otherwise chunk three of "Rate limits" retrieves as an orphan paragraph belonging to nothing. Headings inside fenced code blocks are ignored, because #!/bin/sh is not a section.

For source code, apply the same principle with different boundaries: split on function, class, or module, never mid-body, and carry the imports or the class signature into each chunk as context. For HTML and PDFs, strip to structure first — a splitter fed raw PDF text extraction is splitting page furniture as often as it is splitting content.

How this tool splits

Fixed-size slides a hard window across the raw text with a step of size minus overlap. In token mode the window is converted to characters using the document's own characters-per-token ratio, so the window tracks your text rather than a generic constant.
Sentence and paragraph modes split into whole units first, then greedily pack units until the next one would blow the budget. Overlap is built by walking backwards over complete units, so you never get half a sentence of overlap. A unit that is larger than the target on its own is recursively broken down — paragraph to sentences, sentence to a hard window — which is the only point where a mid-sentence cut can happen.
Markdown sections each pack independently. That means a document with many short sections produces many short chunks, and the tool will not glue two unrelated sections together to hit a target. That is deliberate: a chunk with two topics in it is worse than a chunk that is simply small.
Token counts blend the ~4-characters-per-token rule with a word-based estimate — the same heuristic as my token counter. Expect ±10–20% against a real BPE tokenizer on English, and more drift on code, JSON, and non-Latin scripts.

Two guardrails worth knowing about. Any chunk over 8,192 tokens is flagged, because that is the input ceiling on most current embedding models and anything past it gets silently truncated by the API rather than rejected. And an overlap greater than or equal to the chunk size is the classic infinite-loop footgun in hand-rolled splitters — this one clamps it, warns you, and stops after a hard chunk ceiling instead of locking up your tab.

Questions people ask.

What is the best chunk size for RAG?

There is no universal number, but 512–1024 tokens with 10–15% overlap is a sane starting point for technical documentation, and it is what I reach for first. Go smaller (256–384) when your corpus is FAQ-style and answers are one or two sentences, because precision matters more than context. Go larger (1024–1536) when answers need surrounding narrative to make sense. Then measure retrieval recall on a real question set instead of guessing again.

How much overlap should RAG chunks have?

Ten to fifteen percent of the chunk size, and zero is a legitimate answer once your splitter respects sentence or paragraph boundaries. Overlap exists to stop a fixed-size window from slicing an answer in half; if you are already cutting on real boundaries, most of that risk is gone. Anything above 30% mostly buys you near-duplicate chunks that compete with each other for the top-k slots.

Is the token count in this chunk splitter accurate?

It is an estimate, not a tokenizer. The tool blends the ~4-characters-per-token rule with a word-count estimate, which lands within roughly 10–20% of a real BPE tokenizer on English prose. Code, JSON, non-Latin scripts, and heavy punctuation drift further. Use it to size chunks and compare strategies; use the provider's own tokenizer before you commit a number to a billing forecast.

What is the difference between fixed-size and semantic chunking?

Fixed-size chunking counts characters or tokens and cuts when the counter hits the limit, wherever that lands — often mid-sentence, mid-table, or between a code block and the paragraph explaining it. Structure-aware chunking cuts on boundaries the document already has: sentences, paragraphs, or markdown headings. Semantic chunking goes one step further and cuts where the embedding of consecutive sentences drifts apart. This tool covers the first two, which is where most of the win is.

How do I chunk markdown documents for RAG?

Split on heading boundaries first so each chunk covers one topic, keep the heading line with its body, and only fall back to paragraph or sentence packing inside a section that is still too big. When one section spills into several chunks, re-inject the heading at the top of each continuation chunk — otherwise chunk three of the 'Rate limits' section reads like it belongs to nothing. The markdown mode here does exactly that, and it ignores headings inside fenced code blocks.

Does this chunk splitter send my text anywhere?

No. There is no upload, no API call, and no analytics on the text. The splitting, the token estimate, and the cost maths all run in JavaScript inside your tab, so the page keeps working with the network switched off once it has loaded. Paste internal documentation without thinking about it.

RAG Chunk Splitter.