.jsonl File Validator

Catch dataset errors before they fail your job

A single malformed line can sink an entire fine-tuning job after you have already uploaded and waited. This validator checks every line of your .jsonl file for valid JSON, correct structure and the right roles for your provider, and flags long examples — all locally, before you upload.

How validation works

JSONL stores one independent JSON object per line. The validator parses each line separately so a single bad line does not hide the rest, then applies schema rules for your chosen provider:

• Valid JSON — the line must parse cleanly on its own.
• A messages array — present and non-empty.
• Allowed roles — OpenAI permits system, user, and assistant; Anthropic permits only user and assistant (system is passed separately).
• Non-empty content and at least one assistant turn, since that is what the model learns to produce.

It also computes a rough token estimate per line to warn about examples that may blow past the model’s context window, and checks that the dataset has the minimum number of examples a fine-tuning job requires.

Tips

• Fix the first error first. A stray comma or unescaped quote often explains several downstream failures.
• Match roles to your provider. Moving an OpenAI dataset to Anthropic means lifting the system message out of the array.
• Mind the long lines. A handful of oversized examples can be truncated silently during training — trim or split them.
• Re-validate after every edit so a quick fix does not introduce a new problem.

Understanding the per-line report

Each line in the file gets a pass or fail badge. A passing line shows a brief summary of its message count and approximate token length. A failing line shows the specific error — for example: Invalid JSON on line 14, Missing messages array on line 23, or Unknown role "Human" on line 37. This granularity matters because a dataset of 200 lines might have only two bad ones, and catching them individually is far faster than trying to guess from a single upload error.

The token length warning uses a rough approximation of four characters per token. This is intentionally imprecise — exact tokenisation depends on the model’s tokenizer, which varies by provider and model family. The warning is a safety net to catch obviously oversized examples (a 10,000-character assistant response in one line), not a precise measurement. If you need exact token counts, run your file through a model-specific tokenizer after validating structure here.

OpenAI vs. Anthropic format differences

If you built a dataset for OpenAI and want to use it with Anthropic, the structural change is straightforward: pull the system content out of the messages array and move it to a top-level system key on each line. The validator will flag any system role turns when you switch the schema selector to Anthropic.

Common mistakes and how to fix them

Trailing commas inside content strings. JSON does not allow trailing commas after the last element in an array or object. A common source of this is hand-editing a file that was originally exported as a JavaScript object literal, where trailing commas are valid.

Newlines inside content values. A content string that contains a literal newline (rather than the escape sequence \n) breaks the one-object-per-line invariant and causes the next line to fail parsing too. Replace literal newlines with \n escape sequences inside string values.

Mixed role capitalisation. User (capital U) is not the same as user in JSON. The API requires lowercase role names; the validator flags any that do not match the expected set exactly.