Paste a document to see RAG chunking and embedding cost estimates live. Your text is never uploaded.
Compare per-request and monthly API costs across OpenAI, Anthropic and Gemini, with the price check date.
Open →Estimate the VRAM an LLM needs and check whether it fits on your GPU.
Open →Compare two texts by line, word, or character, with side-by-side or unified views and options to ignore whitespace/case
Open →No comments yet. Be the first!
The RAG Chunk Visualizer lets you paste a document and instantly see how different splitting strategies (fixed size, recursive, by sentence, Markdown headings) cut it into chunks: each chunk gets an alternating tint, overlaps get their own color, and statistics show the chunk count, average and largest tokens, redundancy and chunks that end mid-sentence. Add an embedding model and price to estimate embedding cost and vector-database storage.
There is no universal number. Large chunks blur several topics into one vector and retrieve less precisely; tiny chunks scatter an answer across pieces. A common starting point is chunks of a few hundred tokens with roughly 10% overlap; then check retrieval against the questions you really ask and tune from there.
Overlap lets neighbouring chunks share a little text so information sitting on a boundary is not cut off. The price is that the same text is embedded and stored twice, which raises embedding cost and vector storage directly; the "redundancy" statistic measures exactly that.
Fixed size is simplest and most predictable but may cut sentences. Recursive splitting tries paragraphs, lines, sentences and spaces in turn to stay on natural boundaries and is a good general starting point. Sentence splitting never breaks mid-sentence. Markdown-heading splitting suits structured documents, keeps code blocks whole and records each chunk's heading path.
This tool uses a rough rule (about 4 characters ≈ 1 token in English, about 1 character ≈ 1 token in CJK), while every embedding model has its own tokenizer, so real numbers differ. Treat "tokens (estimated)" as a relative yardstick for comparing settings; for exact figures or to check a model's input limit, confirm with that model's tokenizer.
Storage = chunks × vector dimensions × bytes per dimension (4 for float32, 2 for float16, 1 for int8, 1/8 for binary) × index factor + chunks × payload per chunk. The index factor stands for the extra space an approximate-search index such as HNSW needs on top of the raw vectors, commonly about 1.2 to 2 depending on parameters; you can adjust it.
No. Splitting, statistics and the visualization all run in your browser, and a loaded .txt or .md file is only read locally. The tool calls no embedding API; the embedding cost is just a calculation from the price you enter.
Splits on paragraphs → lines → sentences → spaces, staying on natural boundaries where it can (like the default of popular frameworks).
Overlap 17%
| # | Tokens | Chars | Preview |
|---|---|---|---|
| 1 | 68 | 269 | # Retrieval-augmented generation Retrieval-augmented generation (RAG) combines a search step with a language model. Documents are split into chunks, each chunk· ends mid-sentence |
| 2 | 84 | 309 | ## Why chunking matters If chunks are too large, a single vector blurs several topics together. If they are too small, the answer may be spread across chunks t· ends mid-sentence |
| 3 | 112 | 171 | ## 中文與日本語の例 檢索增強生成會先把長文件切成較小的區塊，再把區塊轉成向量。區塊太大會混入多個主題；區塊太小又可能把答案拆散。検索拡張生成では、文書を適切な大きさに分割することが重要です。 ```python chunks = splitter.split_text(document) print(len(c· ends mid-sentence |
Extra space of an ANN index (e.g. HNSW) relative to the raw vectors; commonly about 1.2–2 depending on parameters.
Embedding dimensions and input limits come from each vendor's docs or model configs (verified 2026-10-20).
Tokens are estimates (about 4 characters = 1 token for English, about 1 character = 1 token for CJK); use your embedding model's own tokenizer for exact numbers. Everything is processed in your browser and the text is not uploaded.
