What chunk size should I use for RAG?

It depends on your documents and embedding model, but 200 to 500 tokens is a common starting point. Smaller chunks match questions more precisely, while larger ones keep more context. Try a few sizes against real questions and compare which chunks are retrieved.

Why add overlap between chunks?

Without overlap, an idea that spans a chunk boundary is cut in half and neither half may match a question well. Repeating the end of each chunk at the start of the next keeps boundary sentences intact in at least one chunk, at the cost of storing a little more text.

How accurate are the token counts?

They are estimates based on about four characters per token. Exact counts depend on each model's tokenizer and can differ by 10 to 30 percent, more for code or non-English text. Use the estimate for sizing, and keep a safety margin under hard model limits.

Does the chunker split on sentences or paragraphs?

It packs as many whole words as fit into each chunk, so boundaries always fall between words but not necessarily at the end of a sentence. Adding overlap is the simplest way to make sure sentences that straddle a boundary remain complete in one of the chunks.

Is my text sent to a server?

No. Chunking runs entirely in your browser with plain JavaScript, and no AI model or API is called. Nothing is uploaded or stored, so it is safe to paste internal documents before deciding what to send to an embedding service.

Text Chunker

Split long text into overlapping chunks by tokens, words, or characters for RAG and LLM prompts.

Runs locally

Split by

Chunk size

Overlap

InputLong text

824 chars · ≈206 tokens

Chunks3 total

#1398 chars · 66 words · ≈100 tokens
Retrieval-augmented generation (RAG) lets a language model answer questions about documents it was never trained on. Instead of pasting a whole manual into the prompt, the documents are split into small chunks, each chunk is turned into an embedding, and only the chunks most similar to the question are sent to the model. Chunk size is a trade-off. Small chunks match a question precisely but can
#2400 chars · 69 words · ≈100 tokens
a trade-off. Small chunks match a question precisely but can lose the surrounding context that makes a passage meaningful. Large chunks keep that context but dilute the embedding with unrelated text and use more of the context window on every request. Overlap softens the hard edges between chunks. When the last few words of one chunk are repeated at the start of the next, a sentence that falls on
#3145 chars · 29 words · ≈37 tokens
repeated at the start of the next, a sentence that falls on a boundary still appears whole in at least one of them, so it can still be retrieved.

Status

Split into 3 chunks of up to 100 tokens, with 15 tokens of overlap.

How it works

Paste a document and it is split into chunks of the size you choose, measured in approximate tokens, words, or characters. Each chunk shows its length and has its own copy button, and the whole set can be copied as a JSON array or as plain text separated by --- lines.

Chunks always end on whole words, so a chunk never stops halfway through one; only a single word longer than the chunk size, such as a long URL, is cut into pieces. Whitespace and line breaks inside each chunk are kept exactly as in the original, and the JSON export includes the start and end offset of every chunk so it can be traced back to its source.

Overlap repeats the last part of one chunk at the start of the next. That way a sentence falling on a boundary still appears whole in at least one chunk, which makes retrieval in RAG systems more reliable. A common starting point is 200 to 500 tokens per chunk with 10 to 20 percent overlap.

Token counts are estimated at about four characters per token, a good average for English text across the tokenizers used by Claude, GPT, and Gemini models. Code, non-English text, and unusual characters often use more tokens, so leave some margin below hard limits such as an embedding model's maximum input.

Frequently asked questions

What chunk size should I use for RAG?: It depends on your documents and embedding model, but 200 to 500 tokens is a common starting point. Smaller chunks match questions more precisely, while larger ones keep more context. Try a few sizes against real questions and compare which chunks are retrieved.
Why add overlap between chunks?: Without overlap, an idea that spans a chunk boundary is cut in half and neither half may match a question well. Repeating the end of each chunk at the start of the next keeps boundary sentences intact in at least one chunk, at the cost of storing a little more text.
How accurate are the token counts?: They are estimates based on about four characters per token. Exact counts depend on each model's tokenizer and can differ by 10 to 30 percent, more for code or non-English text. Use the estimate for sizing, and keep a safety margin under hard model limits.
Does the chunker split on sentences or paragraphs?: It packs as many whole words as fit into each chunk, so boundaries always fall between words but not necessarily at the end of a sentence. Adding overlap is the simplest way to make sure sentences that straddle a boundary remain complete in one of the chunks.
Is my text sent to a server?: No. Chunking runs entirely in your browser with plain JavaScript, and no AI model or API is called. Nothing is uploaded or stored, so it is safe to paste internal documents before deciding what to send to an embedding service.