Split any text into parts that fit a limit: characters, words, exact tokens, sentences, paragraphs, lines or equal parts. Overlap, labels, copy and download.
Token counts use the same o200k tokenizer as the Token Counter (loaded on first use, about 2 MB). Sentence boundaries come from your browser’s language rules.
Paste a long text and get it back in parts that each fit a limit you choose. The limit can be characters, words, exact tokens, sentences, paragraphs or lines, or you can ask for a fixed number of equal parts. Each part comes with its own copy button and a running count of characters, words and tokens; one click copies every part in order, another downloads them as a text file. Nothing is uploaded: the splitting, the sentence detection and the token counting all happen in your browser.
The tool is built for the places where a limit gets in the way of a long text: a prompt that has to fit a model’s context window, a document that has to be chunked for embeddings and retrieval, a post that exceeds a platform cap, a message that runs past an SMS, a transcript that needs to be reviewed in pieces. In every case the hard part is not counting but cutting well, so the defaults keep words and sentences whole and let you add overlap and part labels.
| Mode | The size field means | Best for |
|---|---|---|
| Characters | Maximum characters per part | Character-limited fields, SMS, social posts, form inputs |
| Words | Maximum words per part | Reading in pieces, review queues, translation batches |
| Tokens (o200k) | Maximum tokens per part, counted with the same tokenizer as GPT-5, GPT-4.1 and GPT-4o | Prompts, context windows, embeddings and retrieval chunks |
| Sentences | Sentences per part | Fine-grained chunks, subtitles, sentence-level review |
| Paragraphs | Paragraphs per part | Keeping the author’s own structure; one paragraph per part is a common retrieval unit |
| Lines | Lines per part | Logs, lists, CSV rows, code, anything already one item per line |
| Equal parts | Number of parts | Splitting a job among people or sessions; each part ends on a sentence or word boundary |
When a text is cut into parts for search or for a language model, a fact that sits exactly on a boundary can be lost: half of it in one part, half in the next, and neither half useful alone. Overlap solves that by repeating the tail of each part at the start of the next. Microsoft’s guidance for chunking documents before vector search gives a fixed-size chunk of, for example, 200 words or 600 characters with some overlap, for example 10 to 15 percent of the content, as a reasonable starting point. The overlap field takes the same unit as the mode: characters in character mode, tokens in token mode, whole sentences in sentence mode. In the unit modes the tool carries back complete words or sentences rather than a raw slice, so the repeated tail always reads as text.
Cutting at an exact count is easy; cutting well is not. A period can end a sentence, mark an abbreviation or sit inside a number, and the Unicode text-segmentation standard (UAX #29) says plainly that the period is used ambiguously. With Keep sentences whole on, the tool packs whole sentences into each part and only cuts inside a sentence when a single sentence is longer than the whole part, in which case it tells you. Sentence boundaries come from your browser’s built-in segmenter (Intl.Segmenter), which applies language-specific rules, with a rule-based fallback in older browsers. Keep words whole does the same at word level for character splitting, so a part never ends in the middle of a word.
Language models measure text in tokens, not characters, and a token is not a word: in English prose one token is roughly four characters, but code, other languages and unusual words shift the ratio, so a character count is only a guess. The token mode counts with the o200k encoding, the same one GPT-5, GPT-4.1 and GPT-4o use, exactly as our Token Counter does, so a part sized at 500 tokens is 500 tokens for those models. Claude and Gemini use their own tokenizers; treat the count as a close estimate for them and leave a margin. Embedding models have hard input limits, for instance 8,192 tokens for OpenAI’s text-embedding-3 models, and retrieval works best with chunks far smaller than that, which is what the token mode is for.
Some limits are characters, not tokens. A single SMS carries 160 characters in the GSM 7-bit alphabet defined in 3GPP TS 23.038, and only 70 when the message contains characters outside that alphabet and has to be sent as UCS-2, which is why an accented word or an emoji can double the number of messages. X counts posts up to 280 characters, with some characters weighted as two. Form fields, meta descriptions and app-store listings each have their own caps. Character mode with Keep words whole and labels on produces parts that fit and read in order; check any single part against the Character Counter if the platform counts unusually.
Pick the unit the destination actually counts: tokens for a model, characters for a field, paragraphs when the author’s structure matters. Set the size a little below the real limit to leave room for labels and for tokenizer differences. Add overlap only when the parts will be searched or summarized independently; for a text a person will read in order, overlap is noise. Keep labels on whenever the parts travel separately. Then look at the largest part in the stats row: if one part is much bigger than the rest, a single long sentence or paragraph forced it, and a smaller size or the word-level option will even it out. To count the whole text first, use the Word Counter; to clean an AI answer before splitting it, the AI Text Cleaner.
The splitter is JavaScript running on your device. Your text is never sent anywhere, nothing is stored, and the tokenizer is a file served from this site and loaded only when you choose token mode or when parts are shown, so the count can read as pending for a second on first use. The tool is deterministic and rule-based: it does not understand meaning, so it cannot keep a topic together the way a semantic chunker would, and it does not know your platform’s exact counting rules. What it guarantees is that every part respects the size you set, ends on a word or sentence boundary when you ask it to, and arrives labeled and in order.
Paste it into the Text Splitter, choose the unit the destination counts (characters, words, tokens, sentences, paragraphs or lines), set the maximum per part and, if the parts will be searched separately, an overlap. Each part gets a copy button; Copy all and Download .txt take them in order with [1/N] labels.
It depends on the embedding model and on how specific your queries are, but Microsoft’s guidance for chunking documents before vector search gives a fixed size of, for example, 200 words or 600 characters with 10 to 15 percent overlap as a starting point, and OpenAI’s text-embedding-3 models accept at most 8,192 tokens per input. Use token mode so the size you set is the size the model sees.
It repeats the end of each part at the start of the next, so a sentence or fact that falls on a boundary appears whole in at least one part. It matters when parts are indexed or summarized independently and is unnecessary when a person will read them in order.
Yes. Token mode counts with the o200k encoding used by GPT-5, GPT-4.1 and GPT-4o, so the count is exact for those models. Claude and Gemini tokenize differently, so leave a margin below their limits.
By default, yes. Parts end on sentence boundaries detected by your browser’s language rules, or on word boundaries in character mode. The only time a part cuts inside a sentence is when a single sentence is longer than the whole part, and the tool says so.
No. Splitting, sentence detection, token counting, copying and the .txt download all happen in your browser. The tokenizer is a static file loaded from this site; there is no server, account or logging.