When you split text file content into numbered TXT chunks with Text File Splitter, each run starts with one local TXT, CSV, MD, or LOG file. Select a file no larger than 10 MiB, enter a whole-number maximum from 1 through 100,000, and split the content sequentially. Every complete chunk contains the selected number of logical lines, while the last chunk contains the remaining lines. The tool does not automatically divide a file into equal halves or rebalance the final group. File reading, splitting, and downloads happen locally in the browser, and the original file is never changed.
Understand what counts as one line
The accepted input is one TXT, CSV, MD, or LOG file up to 10 MiB. An empty file is rejected because it contains no meaningful content to partition. Extension checks identify an eligible file type, but they do not prove that CSV or Markdown syntax is valid, and they do not validate the source encoding. The browser reads the chosen file locally and decodes its bytes as UTF-8. If a file uses another encoding, or if binary content has a misleading text extension, the decoded text may contain replacement characters.
Line endings determine the logical line count. Text File Splitter recognizes CRLF, standalone CR, and LF as line boundaries. A CRLF sequence counts as one boundary rather than two. Generated chunks join their lines with LF, so mixed source endings become consistent inside the output parts. Apart from that separator normalization, the character content of each decoded line is preserved, including indentation, trailing spaces, punctuation, and Unicode text.
A trailing line boundary also starts a final logical line. For example, a file containing “a” followed by LF has two logical lines: “a” and an empty final line. Preserving that boundary prevents the source's final newline from being silently discarded. With a chunk size of one, those two logical lines can produce a nonempty first part and an empty final part.
| Detail | Defined Text File Splitter behavior |
|---|---|
| Accepted input | One TXT, CSV, MD, or LOG file |
| Maximum file size | 10 MiB |
| Valid chunk size | A whole number from 1 through 100,000 |
| Line boundaries | CRLF, standalone CR, and LF; CRLF counts as one boundary |
| Trailing boundary | Creates a final empty logical line |
| Line content | Indentation, trailing spaces, punctuation, and Unicode are preserved after decoding |
| Output separators | LF, regardless of the source's mixed line endings |
| Output files | Numbered UTF-8 text files with the TXT extension |
Choose the chunk size for two parts
Text File Splitter groups logical lines sequentially from the first line forward. It does not redistribute lines to balance the final group. To produce exactly two parts, use the verified total logical-line count T and a chunk size K that is less than T but no less than half of T. In other words, T must be greater than K and no greater than twice K. The first part then contains K lines, and the second contains the remaining lines.
For two parts that are as even as possible, round T divided by two upward and enter that value as K only if it is no greater than 100,000. This places K lines in the first part and T minus K lines in the second. If T is odd, the first part contains one more line than the second. That balance comes from the selected chunk size; the tool does not rebalance the groups itself. If T is greater than 200,000, no permitted chunk size can produce exactly two parts.
For example, if the verified total is 10 logical lines and you enter 5, the file is divided into two parts. The first part contains five lines, and the second contains the remaining five lines. If the total is only one logical line, no permitted chunk size can create two parts.
If you do not yet know the total, run a preliminary split with any valid line count and read the displayed logical-line total. You do not need to download the preliminary parts. Adjust the line count to your target, split again, and confirm that the result contains two parts. Changing the line count clears the earlier result so its filenames and counts cannot be mistaken for the new configuration.
Split the file and check the result
- Choose the source file. Open Text File Splitter and select one nonempty TXT, CSV, MD, or LOG file. Confirm that its size is no greater than 10 MiB. A file with another extension is not an accepted input.
- Enter the line count for each part. Use a whole number from 1 through 100,000. To target exactly two parts, select a value that satisfies the relationship between the verified logical-line total and the chunk size. Decimals, zero, negative values, and values above 100,000 are rejected before any chunks are produced, so invalid settings never leave a partial result.
- Split and verify. Start the split, then check the displayed total line count and part count. If the result does not contain exactly two parts, change the line count and run the split again. Changing either the selected file or the line count clears the previous result so old filenames and counts cannot be confused with the new configuration.
- Download the numbered chunks. Download each generated part separately. There is no ZIP archive, so a browser may ask permission when many downloads are requested.
Know what each downloaded part contains
The original base filename is retained and followed by “part” plus a three-digit sequence, such as notes-part-001.txt and notes-part-002.txt. The generated extension is always TXT because every output is a plain UTF-8 text Blob. A source CSV or Markdown file does not produce chunks with those original extensions, and the numbered TXT files should not automatically be treated as independently valid CSV or Markdown documents.
The browser's decoding step follows the behavior described in MDN's File.text documentation, which reads the file's bytes as UTF-8. The downloadable output is created as a Blob. Each download button creates a temporary object URL when clicked, triggers one file download, and revokes that URL immediately. No long-lived object URL is created while the results are displayed.
File reading, splitting, and downloads happen locally in the browser. No source bytes are uploaded to Lizely, and the tool provides no server storage, account, or retained processing history. The same decoded input and line count always produce the same strings, total line count, part count, and zero-padded filenames.
Plan individual downloads for larger splits
Each part has its own download button, and every generated chunk must be downloaded separately. When many parts are requested, the browser may display a repeated-download permission prompt. Use the three-digit part sequence to track the expected order, then compare the number of downloaded files with the displayed part count. This check is especially important when a file contains a trailing boundary, because the documented counting rule can produce an empty final part.
Match the method to the file structure
This is a deliberately plain line-oriented operation. Text File Splitter does not rebalance chunks, split by byte size, split by words, detect paragraphs, or parse records. It also cannot keep a CSV record together when a quoted field contains a newline. JSON, XML, source code, and Markdown constructs can likewise span lines, so a cut at a line boundary may interrupt valid structure.
| Use case | Expected result or precaution |
|---|---|
| Plain lists, logs, subtitle-like rows, simple exports, or text corpora | Well suited to predictable line-based batches |
| CSV with a quoted field containing a newline | A logical record may be divided; use a format-aware CSV parser when record integrity matters |
| JSON, XML, source code, or multi-line Markdown structures | A boundary may interrupt syntax; use a format-aware parser before relying on each chunk independently |
| Non-UTF-8 or binary content with a text extension | Replacement characters may appear after decoding; convert or re-encode the source and review the result |
Protect the original and verify the destination
Keep the source file until every required chunk has been downloaded and checked. The original file is never modified, but its line boundaries are interpreted according to the splitter's documented counting rules, and its output separators are normalized to LF. Review representative chunks—particularly the first, a middle part, and the last—in the application that will use them.
Pay particular attention to trailing empty lines, Unicode characters, indentation, and trailing spaces. An empty final part can be a legitimate result of the trailing-boundary rule. If the destination requires valid CSV, XML, JSON, or Markdown after the split, validate each output with an appropriate parser or converter rather than relying on the source extension alone.