TRAINING DATA · CHECK EVERY LINE
JSONL Training Data Validator
Validate fine-tuning JSONL line by line for chat, instruction or preference records, with the exact reason each line would be rejected.
Your experiment
Start with three chat lines that parse but carry warnings. Turn on strict mode, then load the broken chat file, the Alpaca and preference samples with their own formats, check a chat file as Alpaca, and paste your own lines.
Every input recomputes the result immediately; there is no animation because nothing here unfolds over time. An input outside its allowed range is rejected with a message and the previous valid result stays on screen.
Computed data
Metrics
The rules are this tool's, written to match the record shapes the formats document: chat records need a messages array whose roles are system, user, assistant or tool, string content, at least one assistant message and a weight of 0 or 1 only on assistant messages; Alpaca records need non-empty instruction and output strings; preference records need distinct prompt, chosen and rejected strings. Providers add their own limits, such as token counts per example and minimum example counts, which are not checked here. Nothing leaves the page.
One record per line
JSONL stores one JSON object per line, so a training file can be streamed and a single bad line can be pinpointed. Paste a file into JSONL, one record per line, or load a Sample file; the validator parses every line on its own and applies the rules of the Record format you select: chat records need a messages array of role and content pairs with at least one assistant message, Alpaca records need an instruction and an output, and preference records need a prompt with a chosen and a rejected answer. Errors make the file REJECT; warnings are reported but allowed unless strict mode is on.
Warnings are worth reading
The opening file has 3 lines and all 3 are valid, so it is accepted, but 2 carry warnings: line 2 is a duplicate of line 1, which over-weights that example, and line 3 has an unknown top-level key, meta, that a trainer may ignore or reject. Turn on Strict: treat warnings as errors and the same file gives REJECT with 1 of 3 lines valid. Duplicates are a common result of merging exports, and they quietly bias what the model learns.
The broken file
The broken chat file has 6 lines and only 1 of 6 is valid. Line 1 has a trailing comma and is not valid JSON. Line 2 has no assistant message, so there is nothing to learn from. Line 3 uses the role customer, which no chat format accepts. Line 4 is blank in the middle of the file. Line 5 sends the number 42 as content instead of a string. Each finding names the line, so the fix is mechanical.
Other formats and the wrong format
The Alpaca sample fails on line 3, whose output is empty; an empty target teaches the model to stop immediately. The preference sample fails on line 2, where chosen and rejected are identical, so the pair carries no preference signal. Checking the clean chat file as Alpaca fails on all 3 lines, because each lacks instruction and output and has an unknown key, messages: a quick way to catch a file prepared for the wrong trainer.
Reading the tool and its limits
The bars count ok, warning and error lines, the lanes list every line and the active rules, and the table gives each line's findings. The checks are structural; they cannot tell whether an answer is correct, whether examples leak test data, or whether a provider's token limits are respected. Count tokens with the target model's tokenizer and review a sample of records by hand before training.