Skip to content
Lizely

Text File Splitter

Split one local text file into predictable line-count parts and download every UTF-8 chunk without uploading the source.

Privacy: your files never leave your device. All processing happens locally in your browser.

How to use

  1. 1.Choose one TXT, CSV, MD, or LOG file no larger than 10 MiB.
  2. 2.Enter a whole-number line count for each part.
  3. 3.Split the file, verify total lines and part count, then download each numbered TXT chunk.

About Text File Splitter

Text File Splitter divides one local plain-text file into sequential parts containing a chosen maximum number of lines. Choose a TXT, CSV, MD, or LOG file up to 10 MiB, enter a whole number from 1 through 100,000, split it, and download each part separately. The browser reads and processes the file locally; no bytes are uploaded to Lizely.

The tool recognizes CRLF, standalone CR, and LF as line boundaries. CRLF counts as one boundary. Generated chunks join their lines with LF, so mixed input endings become consistent inside the output parts. The character content of each line is otherwise preserved, including indentation, trailing spaces, punctuation, and Unicode text.

A trailing line boundary creates a final empty line. For example, a file containing “a” followed by LF has two logical lines under the documented rule and can produce an empty final part when the chunk size is one. This explicit treatment prevents the tool from silently discarding a source boundary. Empty files are rejected because there is no meaningful content to partition.

Chunking proceeds from the first line forward. Every complete group contains the requested number of lines except the last, which contains the remainder. The tool does not rebalance chunks, split by byte size, split by words, detect paragraphs, or keep CSV records with embedded quoted newlines together. It is a plain line-oriented operation.

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 the output is a plain UTF-8 text Blob. An original CSV or Markdown extension is not preserved as a claim that every chunk remains independently valid in that format.

Accepted extensions are TXT, CSV, MD, and LOG, but the tool does not validate their syntax or source encoding. Browser File.text decodes the bytes as UTF-8. A non-UTF-8 file or binary file with a misleading extension can contain replacement characters after decoding. Review representative output in the destination application.

The 10 MiB file cap bounds decoding and rendering. Lines per part must be a whole number from 1 to 100,000; decimals, zero, negative values, and larger values are rejected. The limits are checked before producing chunks, and invalid input never yields a partial result.

Each download button creates a temporary object URL at click time, triggers one file download, and revokes it immediately. No long-lived object URL is created during render. Selecting another file or changing the line count clears the old result so filenames and counts cannot be mistaken for the new configuration.

Use this tool to divide manageable lists, logs, subtitle-like rows, simple exports, or text corpora into smaller line batches. It does not create a ZIP archive because no new dependency is introduced; each chunk is downloaded individually. Browsers may ask permission for repeated downloads when many parts are requested.

CSV and structured formats require special care. A quoted CSV field can legally contain a newline, and splitting at that boundary can make invalid fragments. JSON, XML, source code, and Markdown constructs can also span lines. Use a format-aware parser when structural validity matters.

The original file is never changed. Keep it until every required part is downloaded and checked. The same decoded input and line count always produce the same strings, line total, part count, and zero-padded names. There is no server storage, account, or retained processing history.

Methodology & sources

Validate one accepted text filename at or below 10 MiB, decode locally as UTF-8, validate a whole-number chunk size from 1 to 100,000, split CRLF before standalone CR or LF, preserve a trailing empty logical line, slice lines sequentially without rebalancing, join each part with LF, generate zero-padded part filenames, and create and revoke temporary Blob URLs only when each download is clicked.

Frequently asked questions

Are CRLF and LF both supported?
Yes. CRLF, standalone CR, and LF are recognized, and generated chunk boundaries use LF.
Why can a trailing newline create an empty final line?
Every trailing boundary starts a final logical line under the documented counting rule.
Are CSV records kept intact?
No. Splitting is line-based and does not parse quoted multiline CSV fields.
Is the source uploaded?
No. File reading, splitting, and downloads happen locally in the browser.

Related tools

Text Tools guides

View all