A text file on Windows can be split into predictable parts of N lines each using Text File Splitter, a browser tool that reads the file locally, divides it sequentially into whole-number chunks of 1 to 100,000 lines, and offers every numbered part as a separate TXT download under a 10 MiB file cap. The source file never leaves the computer: decoding, slicing, and the temporary download links all run client-side, so the same input combined with the same chunk size always produces the same strings, line total, part count, and zero-padded filenames every time the split runs. The operation is strictly line-oriented, and CRLF, standalone CR, and LF are each recognized as line boundaries, with CRLF counted as one rather than two. Inside each generated part, lines are joined with LF, so a Windows file that mixes CRLF and LF endings becomes consistent inside the output. A trailing line boundary always starts a final logical line, which is why a single-character file followed by a newline has two lines under the documented counting rule and can yield an empty final part when the chunk size is one.
The original base filename is retained and combined with part plus a three-digit sequence, such as notes-part-001.txt and notes-part-002.txt, and the generated extension is always TXT regardless of what the source file was called. Because chunking proceeds from the first line forward, every complete group contains the requested number of lines except the last, which holds the remainder, and there is no rebalancing, byte-size splitting, or paragraph detection at any stage.
Why a Browser Splitter Works Well on Windows
Several built-in and third-party options exist on Windows for splitting text. PowerShell's Get-Content paired with a counter and a writer can chunk a file, but the loop, the file naming, and the encoding handling are all on you. Notepad++ has built-in split behavior for very large files, but it operates on view state rather than producing clean line-based exports. Installable utilities such as GSplit or HJSplit can divide files by byte count, but each one introduces another program you have to trust with your data and learn to drive. For plain text where you want parts based on a clean line count, a browser-based approach removes the installer, the registry entries, and the update cycle: open the page, pick the file, type the chunk size, and download.
Text File Splitter is built around that idea. The whole pipeline runs in the browser, the source is decoded with File.text as UTF-8, and the chunks are delivered one at a time through temporary Blob URLs that the page revokes immediately after each click. No administrator rights, no package manager, and no specific browser edition are required on Windows 10 or 11.
Split a Text File in Windows Step by Step
Open Text File Splitter in Edge, Chrome, Firefox, or any modern browser on the Windows machine that holds the file, then work through the following sequence.
- Click the file input and select one local TXT, CSV, MD, or LOG file no larger than 10 MiB. Files outside that cap are rejected before any decoding work happens, and empty files are rejected for the same reason.
- Enter the maximum number of lines per part as a whole number between 1 and 100,000. Decimals, zero, negative numbers, and values above 100,000 are rejected before any chunks are produced.
- Click the Split button and wait for the tool to report the total line count and the number of parts. Because chunking proceeds from the first line forward, every complete group contains the requested number of lines except the last, which carries the remainder.
- Compare the reported line total against what you expect from the source. For a 500-line file at a chunk size of 100, the result is exactly 500 ÷ 100 = 5 parts of 100 lines each. For a file that does not divide evenly, the final part is shorter and contains the leftover lines.
- Click each numbered download button in turn to save its TXT part. Browsers may ask permission to download multiple files when many parts are requested.
- Keep the original file until every part is downloaded and confirmed in the application that will use the data, because the splitter never modifies the source.
How Line Counting Works Inside the Tool
The line-counting rules are explicit because Windows text files frequently mix CRLF with older LF content. CRLF, standalone CR, and LF are each treated as line boundaries, and CRLF counts as one boundary. The output chunks use LF for every line break, so a source file that mixes endings becomes consistent inside the parts.
A trailing line boundary starts a final logical line, which is the most common source of off-by-one surprise. A file containing the letter a followed by a single newline has two lines under the documented counting rule and can yield an empty final part when the chunk size is one. Indentation, trailing spaces, punctuation, and Unicode characters inside each line are preserved exactly. The tool does not rebalance, byte-size, split by words, detect paragraphs, or keep CSV records together; the operation is plain line-oriented end to end.
File Types That Need Extra Caution
The tool does not validate the syntax or source encoding of the file you point it at. The accepted extensions are TXT, CSV, MD, and LOG, but the splitter does not parse the structure of any of them. A quoted CSV field can legally contain a newline, and splitting at that boundary can produce fragments that will not round-trip through a CSV parser. JSON, XML, source code, and Markdown constructs can also span multiple lines, so cutting on a fixed line count can break a heading, a fenced code block, or a table.
If the file is not actually UTF-8, File.text decoding can produce replacement characters in the output, which is more common with files saved by older Windows tools in CP-1252 or other legacy encodings. Always preview a representative part in the destination application before deleting the source. For a specific half-split workflow where the chunk size is half the line total, the dedicated guide on how to split a text file in half by lines walks through that calculation in detail.
Limits, Filenames, and What Gets Downloaded
The interaction surface is small, which makes the limits worth knowing up front:
| Setting | Accepted value |
|---|---|
| File size cap | 10 MiB (10,485,760 bytes) |
| Accepted extensions | TXT, CSV, MD, LOG |
| Lines per part | Whole number from 1 to 100,000 |
| Line endings recognized | CRLF, standalone CR, LF |
| Line endings in output | LF only |
| Output extension | TXT, always UTF-8 |
| Filename pattern | basefilename-part-XXX.txt |
| Archive packaging | None; each part downloads individually |
| Processing location | Browser, local only; no upload |
The Blob URL that backs each download is created on click and revoked immediately after the browser hands the file off, so no long-lived object URL stays in memory between clicks. Selecting another file or changing the chunk size clears the previous result so old filenames and counts cannot be mistaken for the new configuration. There is no server storage, no account, and no retained processing history; once the tab closes, the only copy of the split parts is the one you downloaded.
Verifying and Rejoining the Parts on Windows
The fastest sanity check is to confirm the line total reported by the tool matches what the destination application sees when it opens the source. The tool reports total lines and part count after the split, and because every complete group is the requested size except the final remainder, the part count can be predicted from the line total. Each part keeps its characters exactly, modulo the LF normalization, so rejoining them on Windows is straightforward: in PowerShell, pipe the contents of the numbered parts in order into Set-Content, or open them sequentially in Notepad++. The expected result is byte-identical to the source apart from the consistent LF endings inside each part.
For files that exceed 10 MiB, the splitter refuses them up front rather than producing a partial result. Splitting a larger file means doing it in two or more passes and keeping the part counts straight by hand, or pre-trimming the file with another utility. If the file's lines need additional cleanup before or after the split, such as removing duplicates, sorting, or stripping whitespace, those are separate operations: the splitter does not edit the character content of any line.