> Source: https://txtfetch.com/fixes/no-paragraph-breaks > Plain-text twin — every page on txtfetch.com has one. https://txtfetch.com/text --- # My extracted text is one giant block with no paragraph breaks anywhere. A paragraph break is really just a whitespace pattern, a blank line. It only survives if the source document encoded one in the first place. Some sources genuinely don't have one. looks-like ``` Sentence one keeps this block going. Sentence two keeps this block going without any blank line anywhere in it. Sentence three keeps this block going the exact same way, and so does every sentence after it for the rest of the document. ``` Sentence boundaries survive, since a period is still a period. But the higher-level grouping a real paragraph represents is gone. why-it-happens A paragraph break in extracted text is really just a specific whitespace pattern: a blank line, or two consecutive newlines. That pattern only survives if the source document encoded paragraphs as a real structural break in the first place. The extractor also has to preserve it. Some sources genuinely don't have one. A single long text block pasted into a form field is one example. So is a PDF built from a layout engine that treats the whole page as one flow, with no paragraph-level markup. An aggressive reflow step can also strip blank lines along with the print-line breaks it was trying to fix. Without that signal, there's nothing left in the text itself to mark where one idea ends and the next begins. Sentence boundaries survive, since a period is still a period. But the higher-level grouping a real paragraph represents is gone. confirm-it - Paste the text into the chunk previewer. A document longer than 2,000 characters with zero blank-line breaks anywhere trips this signal. [Scan for missing paragraph breaks](https://txtfetch.com/tools/chunk-preview) fix-it-yourself Fall back to sentence-boundary splitting explicitly When there's no paragraph signal to key off, group a fixed number of sentences together as a paragraph substitute. This is better than letting a chunker degrade silently to line-level splitting. python ``` import re sentences = re.split(r"(?<=[.!?])\s+", text) paragraphs = [" ".join(sentences[i:i+5]) for i in range(0, len(sentences), 5)] text_with_breaks = "\n\n".join(paragraphs) ``` Use a real sentence tokenizer for cleaner boundaries A proper sentence segmenter handles abbreviations, decimals, and quoted sentences far more reliably than a punctuation regex. That matters once you're relying on it to define chunk-worthy groups. The model is a separate download from the package. Without it, spacy.load() raises OSError: \[E050\] Can't find model 'en\_core\_web\_sm'. python ``` # pip install spacy # python -m spacy download en_core_web_sm import spacy nlp = spacy.load("en_core_web_sm") sentences = [s.text for s in nlp(text).sents] ``` what-txtfetch-does txtfetch preserves whatever paragraph structure the source document actually encoded. It doesn't invent breaks that weren't there, and it doesn't strip real ones. If the source genuinely has no paragraph-level structure, the extracted text won't either. A single flowed text block, a plain .txt file authored that way, and a form-field export are all examples. There's nothing there to recover. This is a property of the input, not something the extraction step can fix without guessing at document structure the source never provided. what-it-costs-you-downstream With no paragraph breaks to key off, recursive and structure-aware chunking both fall back to splitting on sentences or lines. This effectively degrades to the same boundary quality as fixed-size chunking, the one strategy explicitly designed to ignore structure. faq **Can extraction add paragraph breaks that aren't in the source?**: No, and it shouldn't try to. Inventing a break where the source document didn't encode one is a guess about document structure that's just as likely to be wrong as right. txtfetch returns exactly the paragraph structure (or lack of it) the source actually has. **What should I use instead of paragraph breaks for chunking this kind of text?**: Sentence-boundary splitting, grouped into fixed-size batches, is the practical substitute. See the fix-it-yourself snippets above. It won't recover real semantic paragraph groupings that were never there, but it avoids degrading all the way to line-level or fixed-character chunking. **Is this the same problem as hard-wrapped lines?**: Related but distinct. Hard-wrapped text has too MANY line breaks (one per print line, no paragraph grouping). This is text with too FEW (none at all). See /fixes/hard-wrapped-lines for the other shape. related-reading - [Hard-wrapped lines →](https://txtfetch.com/fixes/hard-wrapped-lines) - [Chunking strategies for RAG →](https://txtfetch.com/blog/chunking-strategies-for-rag) - [Chunk previewer →](https://txtfetch.com/tools/chunk-preview) Layout & structure - [two-column PDF text comes out interleaved and scrambled →](https://txtfetch.com/fixes/columns-out-of-order) - [PDF or scanned tables flatten into unreadable space-separated text →](https://txtfetch.com/fixes/tables-lose-structure) - [the same header, footer, or page number shows up in every chunk →](https://txtfetch.com/fixes/headers-and-footers-in-every-chunk) - [extracted text is hard-wrapped at the print page's line width →](https://txtfetch.com/fixes/hard-wrapped-lines) - [All fixes →](https://txtfetch.com/fixes) ## Fix the text you already have. The free cleaner repairs this damage in your browser. Nothing leaves the page. [Clean up your text →](https://txtfetch.com/tools/clean-extracted-text) [Get an API key →](https://app.txtfetch.com/signup)