recursive-char (default). Probeert eerst op alinea-breaks te splitsen, dan op regelbreaks, dan op zinsgrenzen ( . ), dan op spaties. Elk stuk wordt gulzig opgepakt tot de chunk-grootte. Valt alleen terug op een harde karakter-split als niets anders past. Default in LangChain, LlamaIndex en de meeste productie-RAG-stacks; verstandig startpunt voor bijna elk prozacorpus. sentence . Splitst op zinsgrenzen en nooit binnen een zin — ook als een zin korter is dan de budget, blijft hij heel. Beter dan recursive-char wanneer chunks als bewijs worden geciteerd (QA, citaten), omdat geen chunk midden in een gedachte eindigt. Chunk-groottes variëren meer, omdat zinnen dat doen. paragraph . Behandelt elke alinea als eenheid. Twee aangrenzende korte alinea's kunnen samen worden gepakt, maar een lange alinea wordt nooit gesplitst. Handig voor documentatie, KB-artikelen en goed opgemaakte long-form waar elke alinea een coherente gedachte is. semantic . Voegt heading-detectie toe bovenop paragraph: regels die beginnen met # , ## enz., of korte all-caps regels, worden behandeld als sectie-breaks. Goed voor technische documentatie waar sectiegrenzen meer tellen dan visuele alinea-spacing.

Het is een heuristiek. tekens / 3.8 voor Engels-achtige tekst en 1 token per teken voor CJK. ±5–10% voor proza, slechter voor code-zware of gestructureerde tekst. Waarom niet de echte tokenizer? tiktoken is ~1 MB WASM — te zwaar om alleen voor chunk-sizing te shippen. Als je downstream-model een harde token-limiet op chunks heeft (sommige doen dat, bv. cohere/embed-v3 is gecapt op 512), bouw met een veiligheidsmarge of draai de echte tokenizer in je pipeline. Dit is prima voor sizing. Het exacte token-aantal per chunk doet er voor RAG-kwaliteit weinig toe — het embedding-model truncatert oversized inputs sowieso. Wat telt is consistentie: dezelfde heuristiek voor chunking en voor het budgetteren van downstream-prompts.

RAG Text Chunker

Splits tekst in chunks van token-grootte voor RAG / embeddings-voorbereiding. Meerdere strategieën: recursive char, sentence-aware, semantic boundaries. Configureerbare overlap. Allemaal in de browser.

Paste your document

RAG (Retrieval-Augmented Generation) is a technique that pairs an LLM with an external knowledge base. Instead of relying only on the model's parametric memory, the system retrieves relevant passages at query time and concatenates them into the prompt.

The retrieval step depends on a vector store. Documents are split into chunks, each chunk gets an embedding vector, and those vectors are stored in a database that supports approximate nearest-neighbour search.

# Chunk size matters

Chunks that are too small lose context — a single sentence might not contain enough information to answer the question. Chunks that are too large dilute relevance — the embedding becomes an average of many unrelated topics, and retrieval gets noisy.

A common starting point is 500 tokens per chunk with 50 tokens of overlap. Overlap lets a chunk see a bit of context from its neighbours, which helps when a relevant span happens to fall across a chunk boundary.

# Strategy choice

Recursive character splitting is the most general: it tries paragraph breaks first, then line breaks, then sentence boundaries, then spaces. This is the default in most frameworks and works well for prose.

Sentence-aware splitting respects sentence boundaries and never breaks mid-sentence. It produces cleaner chunks for QA over articles and books, at the cost of more variable chunk sizes.

Paragraph chunking treats each paragraph as its own chunk (subject to the size limit). This is useful for structured documents like documentation or knowledge-base articles where each section is already a coherent unit.

Semantic chunking goes one step further: it tries to keep semantically related content together by respecting headings and topic boundaries, even when those don't align with paragraph breaks.

Chunk size (tokens): 500

Overlap (tokens): 50

Strategy

Waar is dit voor?

Retrieval-Augmented Generation (RAG) en embedding-gebaseerd zoeken hangen beide af van het splitsen van een corpus in chunks: kleine stukken die afzonderlijk worden embed en in een vector-DB opgeslagen. De split gebeurt vóór alle AI-machinerie, maar de kwaliteit van je retrieval hangt er stilletjes meer van af dan de meeste mensen beseffen. Te kleine chunks verliezen context; te grote verdunnen relevantie; midden in een zin gesplitste chunks retrieven slecht omdat de embedding op een rare semantische plek belandt. Deze tool is een snelle in-browser-playground om te experimenteren met chunk-grootte, overlap en strategie voordat je een pipeline op de keuze vastlegt.

De vier strategieën

recursive-char (default). Probeert eerst op alinea-breaks te splitsen, dan op regelbreaks, dan op zinsgrenzen (. ), dan op spaties. Elk stuk wordt gulzig opgepakt tot de chunk-grootte. Valt alleen terug op een harde karakter-split als niets anders past. Default in LangChain, LlamaIndex en de meeste productie-RAG-stacks; verstandig startpunt voor bijna elk prozacorpus.
sentence. Splitst op zinsgrenzen en nooit binnen een zin — ook als een zin korter is dan de budget, blijft hij heel. Beter dan recursive-char wanneer chunks als bewijs worden geciteerd (QA, citaten), omdat geen chunk midden in een gedachte eindigt. Chunk-groottes variëren meer, omdat zinnen dat doen.
paragraph. Behandelt elke alinea als eenheid. Twee aangrenzende korte alinea's kunnen samen worden gepakt, maar een lange alinea wordt nooit gesplitst. Handig voor documentatie, KB-artikelen en goed opgemaakte long-form waar elke alinea een coherente gedachte is.
semantic. Voegt heading-detectie toe bovenop paragraph: regels die beginnen met #, ## enz., of korte all-caps regels, worden behandeld als sectie-breaks. Goed voor technische documentatie waar sectiegrenzen meer tellen dan visuele alinea-spacing.

Overlap — waarom en hoeveel

Waarom. Als een relevante span precies over de grens tussen twee chunks valt, retrieven beide slecht omdat elk maar de helft heeft. Overlap kopieert de laatste N tokens van de vorige chunk naar de voorkant van de volgende, zodat beide de span kunnen vangen.
Hoeveel. 10–20% van de chunk-grootte is de vuistregel. Voor 500-token chunks: 50–100 tokens overlap. Default hier is 50, werkt goed in praktijk.
Trade-off. Meer overlap = meer totale embeddings (meer storage, meer kosten, langere index-build, meer retrieval-kandidaten). Ga niet boven 30% zonder specifieke reden; je verspilt geld zonder de retrieval veel te verbeteren.

Token-schatting

Het is een heuristiek. tekens / 3.8 voor Engels-achtige tekst en 1 token per teken voor CJK. ±5–10% voor proza, slechter voor code-zware of gestructureerde tekst.
Waarom niet de echte tokenizer? tiktoken is ~1 MB WASM — te zwaar om alleen voor chunk-sizing te shippen. Als je downstream-model een harde token-limiet op chunks heeft (sommige doen dat, bv. cohere/embed-v3 is gecapt op 512), bouw met een veiligheidsmarge of draai de echte tokenizer in je pipeline.
Dit is prima voor sizing. Het exacte token-aantal per chunk doet er voor RAG-kwaliteit weinig toe — het embedding-model truncatert oversized inputs sowieso. Wat telt is consistentie: dezelfde heuristiek voor chunking en voor het budgetteren van downstream-prompts.

Veelvoorkomende valkuilen

Chunk geen gestructureerde data (JSON, CSV) met een tekst-chunker. De chunk-grenzen vallen midden in records en de embeddings worden betekenisloos. Splits eerst op record-grenzen, of gebruik een tool-specifieke RAG-aanpak.
Chunk geen code met een proza-chunker. Voor code-retrieval tellen functie-grenzen, niet karakter-aantallen. Tree-sitter-gebaseerde chunkers bestaan hiervoor.
Whitespace en BOM. Geplakte tekst kan verborgen whitespace dragen die token-schattingen verstoort. Trim en normaliseer voor het plakken als het ertoe doet.
Privacy. Alles draait in de browser. Hier geplakte documenten verlaten de pagina nooit; je kan dit gebruiken voor vertrouwelijk of PII-bevattend materiaal zoals je een lokaal script zou gebruiken.