TEST CASE
PARSERCOMPETITIVE PROGRAMMING TOOLKIT

How to split contest test input into separate files

Contest problems often give you one block of sample input that actually holds several test cases. To test a solution locally you usually want each case in its own file, so you can run ./solution < 1.txt and compare the output with the expected answer. Splitting by hand is slow and easy to get wrong. The parser above does it in one click, entirely in your browser.

Using the parser

1. Paste your raw input into the box, or load one of the quick examples (Codeforces style, AtCoder style, multi-case, graph problem, EOF terminated).
2. Choose a split mode that matches how the cases are separated.
3. Set an output filename prefix, then press Parse.
4. Preview each case, open it full size, copy it, or download it as a numbered .txt file. “Download All (.zip)” bundles every case together.

While you type, the counters show the number of lines and characters and a live estimate of how many cases were detected.

The four split modes

• Blank line between cases: every run of one or more empty lines starts a new case. This suits samples where cases are visually separated.
• First line = number of cases: the first line is read as T, then the rest is split on blank lines and only the first T cases are kept. If the first line isn’t a positive integer, the parser tells you instead of guessing.
• Custom delimiter: split on any string you choose, such as --- (the default) or ###.
• Every N lines: cut the input into chunks of exactly N lines. This works when every case has the same shape, such as two lines each.

Which mode fits which format?

Many Codeforces problems start with a number t followed by t cases that are not separated by blank lines:

3
2
1 2
2
3 4
1
5

Here the cases have different lengths, so “every N lines” will not work. Because there are no blank lines, the “first line = number of cases” mode would also see one big block. In that situation, add a separator line between cases by hand and use the custom delimiter mode. For fixed-shape cases, such as a pair of lines per test, “every N lines” is the quickest choice. For samples that already have blank lines between them, the blank-line mode is the right one.

Things to know

• Each case is trimmed. Leading and trailing whitespace is removed. Problems that care about exact trailing spaces are rare, but check if yours is one of them.
• Blank lines inside a case will break the blank-line mode, for example in a grid with empty separator rows. Use a custom delimiter for those.
• Check the count. If the number of parsed cases isn’t what you expected, the split mode is usually the culprit. Try another one and compare.

A simple local testing routine

1. Parse the sample input and download the zip.
2. Run your program on each file and save the results.
3. Compare them with the expected output using a tool such as diff.
4. When a case fails, open it in the preview, shrink it by hand, and debug the smallest failing input.

Frequently asked questions

Is my input uploaded anywhere?

No. Splitting and zipping both happen in your browser, so your input is not sent to a server.

Does it work for LeetCode and AtCoder problems?

Yes, as long as you can describe how the cases are separated. The tool only splits text, so it doesn’t need to know which site the problem came from.

Can I change the file names?

Yes. Set the filename prefix before parsing and every downloaded file will use it with a case number.

Is there a limit on input size?

There is no fixed limit, but very large inputs depend on your browser’s memory, so split huge files in a command-line tool instead.