★ Token-Based chunking, visualized
Token-Based Chunking for RAG
Token-based chunking is a fixed window measured in tokens instead of characters. The text is tokenized, cut every N tokens with an overlap, and each window is decoded back to text.
- Runs in your browser
- No signup
1,181 characters · loading tokenizer… · nothing leaves your browser
Counts tokens with the o200k_base tokenizer.
Fixed (tokens) · 80 tokens · overlap 10
5 chunks
- 67
- avg tokens
- 15 / 80
- min / max
- 40
- overlap tokens
- $6.70
- embed 1M docs
Loading the tokenizer; token counts are estimates until it's ready.
one chunkoverlapClick a chunk to inspect it.
Chunk inspector
Click any coloured chunk in the document to see its text, size, heading path and what it shares with its neighbours.
Chunk sizes
Tokens per chunk (estimated). A tight cluster means predictable chunks.
Embedding cost assumes text-embedding-3-small at $0.02 per 1M tokens (OpenAI, checked 8 Nov 2026), counting overlap twice.
Export config
Copy-ready code for the strategy and settings above. Comments flag where a library differs.
from langchain_text_splitters import TokenTextSplitter
splitter = TokenTextSplitter(encoding_name="o200k_base", chunk_size=80, chunk_overlap=10)
chunks = splitter.split_text(text)Your retrieval is only as good as your chunks.
I build RAG systems with evals, so you know when the answers get better or worse.
How it works
Token-based chunking is a fixed window measured in tokens instead of characters. The text is tokenized, cut every N tokens with an overlap, and each window is decoded back to text.
This visualizer uses the o200k_base tokenizer. Your embedding model may tokenize differently, so treat the counts as close, not exact, unless you use the same tokenizer.
When to use it
Good fit
- When you must stay under an embedding model's token limit with no surprises.
- When cost per chunk needs to be predictable.
- Mixed-language or code-heavy text, where characters per token vary a lot.
Watch out for
- Still blind to structure: it cuts sentences and code wherever the window ends.
- Tokenizer mismatch: counting with one tokenizer and embedding with another drifts.
- Very small windows lose context; very large ones dilute the embedding.
Where to start
A few hundred tokens with an overlap of around a tenth of that is a common starting point. Tune it with an evaluation set rather than by feel.
Then test it: write down twenty real questions, check which chunks come back for each, and compare strategies on the same set. The main visualizer lets you put two strategies side by side.
Questions engineers actually ask
Which tokenizer should I count with?
Does overlap help retrieval?
Is token-based better than recursive?
What chunk size should I use for RAG?
Does my text leave the browser?
Other strategies
More from the workbench
Fine print
Tools: on the house.
Engineer: by the hour.
The visualizer was free. Production RAG with evals is what I build.
I'm Himanshu, an AI and full-stack engineer. I build MVPs, AI agents and the growth plumbing around them for early-stage startups.
