Can the tool split a file into exactly two equal halves automatically?

No. You set the lines-per-part value yourself, so you compute the half as ceil(total lines divided by 2) before you split. An odd total produces one part that is one line shorter than the other because the tool does not rebalance.

Is the source file uploaded to a server?

No. File reading, splitting, and downloads all happen locally in the browser. No bytes are sent anywhere and no processing history is retained.

What happens to line endings when the file is split?

CRLF, standalone CR, and LF are all recognized as line boundaries, with CRLF counted as one boundary. Every chunk is joined with LF in the output, so mixed endings inside a single source become consistent inside each part.

Why does a file ending with a newline sometimes create an empty final part?

A trailing line boundary starts a final logical line under the documented counting rule, so a file like "a\n" has two lines. With a chunk size of 1, part 001 contains "a" and part 002 contains the empty final line.

Does the tool keep CSV records with embedded quoted newlines together?

No. Splitting is purely line-based and does not parse quoted multiline CSV fields. If a field contains a real newline, the cut can fall inside that quote and produce fragments that no longer parse as valid CSV.

What are the size and chunk limits?

The source file must be at or below 10 MiB, and lines per part must be a whole number from 1 to 100,000. Invalid values are rejected before any chunk is produced, so you never see a partial result from a bad input.

How to Split a Text File in Half by Lines

Halving a text file means dividing it into two parts that each contain roughly the same number of lines, and the most reliable way to do it is to count the lines first, set a chunk size equal to half that total, and run a local line-based splitter. With a 1,000-line file you split it at 500 lines per part; with a 1,001-line file you set the chunk size to 501, which produces a 501-line first part and a 500-line second part because the splitter does not rebalance the remainder. The split happens at line boundaries, and every CRLF, CR, or LF terminates one logical line, so indentation, Unicode characters, and trailing spaces on each line survive intact. There is no automatic "make exactly two equal halves" button in any plain-text tool, because equal halves require you to know how many lines you have before you commit to a chunk size. That is why a quick line count plus a single chunk-size input are enough to get the job done without uploading anything.

What "split in half" really means for a plain-text file

Text files are sequences of lines, and a "half" is just a partition of those lines into two groups. The most predictable definition is by line count: half of 400 lines is 200 lines in each part. Alternatives exist, and they give different answers.

Line count: every line is one unit, regardless of how long it is. Predictable and matches what most editors and parsers see.
Byte size: each part is capped by kilobytes or megabytes. Useful when storage is the constraint, but uneven line lengths produce uneven line counts.
Percentage: a request like "50%" is shorthand for "half the lines" or "half the bytes" — you still convert it into a concrete number before you click anything.

For ordinary notes, log files, simple exports, and text corpora, line count is the safest definition. It also matches how tools like Text File Splitter actually work: one chunk size in, N parts out, where N equals the ceiling of total lines divided by chunk size.

Count the lines before you set the chunk size

You cannot pick a half until you know the total. Open the file in a local line counter to get a precise total, then divide by two and round up if the total is odd.

The Line Counter returns the total, non-blank, and blank line counts in one pass without uploading anything: paste, count, done. With the total in hand, the formula is direct:

Chunk size = ceil(total lines divided by 2)

For a total of 200 lines, ceil(200 divided by 2) equals 100. For 349 lines, ceil(349 divided by 2) equals 175. For 10,007 lines, ceil(10,007 divided by 2) equals 5,004. In every case the second part absorbs whatever is left over, and the splitter never silently drops lines, so the sum of the parts always equals the total.

Split your text file in half with Text File Splitter

Open Text File Splitter in your browser. The page reads and processes files locally, so nothing is sent to a server.
Choose one local file with a TXT, CSV, MD, or LOG extension that is at or below 10 MiB. Files outside that size limit are rejected before splitting begins.
Enter your half-size in the lines-per-part field as a whole number from 1 to 100,000. For a 349-line file, enter 175 to get two parts.
Run the split and read the displayed totals: the tool confirms the total line count it read and the number of parts it produced.
Download each numbered chunk individually. Filenames follow the pattern yourname-part-001.txt, yourname-part-002.txt, and so on, always with a .txt extension and a three-digit zero-padded sequence.
Keep the original file on disk until every chunk is downloaded, opened, and verified in your destination application.

For the 349-line example above, the math is 349 divided by 175 equals 1.994, rounded up to 2 parts, and the resulting split is 175 lines in part 001 plus 174 lines in part 002. The arithmetic 175 plus 174 equals 349 confirms no lines were dropped or duplicated.

Inside the splitter: line rules and output behavior

Text File Splitter is a strict line-oriented tool, and a few specifics matter when the goal is to land on an exact half:

Line boundaries: CRLF, standalone CR, and LF are all recognized. CRLF counts as one boundary, not two.
Trailing empty line: a file that ends with a line break contains a final empty logical line. The two-character input "a\n" has two lines, so a chunk size of 1 yields part 001 with "a" and part 002 with the empty line.
Output line breaks: every chunk is joined with LF regardless of the source's mixed endings, so the parts use consistent line breaks.
No rebalancing: the last part carries the remainder. There is no algorithm to make both halves exactly equal when the total is odd.
No ZIP archive: parts are downloaded one at a time so the tool adds no extra dependencies. Browsers may prompt for permission when many parts are requested.
Deterministic filenames: the same input and chunk size always produce the same total, part count, and zero-padded names.

Limit	Documented value	Behavior at the boundary
Maximum source size	10 MiB	Larger files are rejected before any decoding begins.
Lines per part	Whole number, 1 to 100,000	Zero, decimals, negatives, and values above the cap are rejected; no partial result is produced.
Accepted extensions	TXT, CSV, MD, LOG	Other extensions are rejected; the tool does not inspect format syntax.
Source encoding	UTF-8 (decoded by File.text)	Non-UTF-8 or binary files with a misleading extension may surface replacement characters.

Under the hood the tool validates the filename and size, decodes the bytes as UTF-8, validates the chunk size, splits CRLF before standalone CR or LF, preserves a trailing empty logical line, slices lines sequentially without rebalancing, joins each part with LF, generates zero-padded filenames, and creates a temporary object URL only when you click a download button. That object URL is revoked immediately after the download fires, so nothing lingers in memory. The implementation follows the File.text decoding pattern documented by MDN.

Watch out when halving structured files

Line-based splitting is exact but it does not respect structure. A file that looks like ordinary text can carry lines that only make sense when kept with their neighbors.

CSV with quoted newlines: a quoted CSV field can legally contain a real newline. If the boundary lands inside that quote, the resulting halves will not parse as valid CSV.
Markdown tables and fenced code blocks: a fence opened on line 200 and closed on line 320 will be torn in half if your split point falls inside it.
Subtitle files: SRT and similar formats use numbered cue blocks separated by blank lines; cutting at the line level can split a single cue across two parts.
Logs with stack traces: a multi-line stack trace attached to one log entry can be split off from its parent line.

If structural validity matters, use a format-aware parser before you halve, or choose a chunk size that you have manually confirmed lines up with the natural boundaries in your file. For plain prose, plain log lines, and simple exports, the line-based approach is exactly what you want.

Keep the original and verify both halves

The original file is never modified — the tool only reads it. Treat it as the source of truth: keep it on disk until you have downloaded both halves and confirmed them. A quick verification looks like this:

Open part 001 in any plain-text editor. Confirm that its first line matches the original file's first line.
Open part 002 and confirm that its last line matches the original file's last line.
Add the two part line counts together and compare to the original total. The numbers must match exactly.
Open at least one part in the application that consumes the format (a CSV importer, a Markdown renderer, a log viewer) and confirm it parses without errors.

Once everything checks out, the halves are interchangeable with the original in any tool that reads them sequentially. If you ever need to reassemble them, the Text File Merger rejoins files in a chosen order with an explicit separator rule. For most "split in half" tasks, however, the two parts stay separate: one for sharing and one for archiving, one for upload and one for local reference, or one for the first half of processing and one for the second.