JSONL Validator for Fine-Tuning Datasets — Free
Validate a JSONL file line by line and check every record against the OpenAI and Anthropic chat fine-tune schema before you upload it.
Frequently Asked Questions
What does the validator check?
First that every non-blank line is valid JSON on its own. Then, for records containing a messages array, that the array is non-empty, that each message has a recognised role and a content field, and that the example contains an assistant message to train against. It also counts records and flags duplicates.
Why does a missing assistant message matter?
Fine-tuning learns to produce the assistant turn. An example ending on a user message gives the model no target output, so it contributes nothing to training and is usually a data-preparation bug.
Does it validate non-chat JSONL?
Yes. Records without a messages array are still checked for valid JSON, object shape and duplication — the chat schema checks simply do not apply to them.
Why are duplicates worth flagging?
Duplicated examples silently over-weight whatever they teach, and they usually indicate a bug in the export script rather than an intentional choice.
Is my dataset uploaded for validation?
No. Everything runs in your browser, so proprietary or personal training data never leaves your machine.
Privacy First: All processing happens directly in your browser. Your data never leaves your device.
About JSONL Validator
A fine-tuning upload that fails after a long queue wait, on line 40,000 of your dataset, is an expensive way to discover a formatting bug. Validating locally first catches the same problems in a second.
Two layers of checking
The first layer is structural: every non-blank line must be valid JSON on its own. This catches truncated writes, pretty-printed records that span lines, and stray text — the failures that make a provider reject the file outright.
The second layer applies to records that contain a messages array, and checks them against the chat fine-tune schema: the array must be non-empty, every message needs a recognised role and a content field, and the example must contain an assistant turn.
Why an assistant message is required
Supervised fine-tuning teaches a model to produce the assistant turn given everything before it. An example that ends on a user message provides no target output, so it contributes nothing to training while still counting toward your token bill.
This is almost always a bug in the export script rather than a deliberate choice — typically an off-by-one when pairing prompts with completions, which silently drops the last response of every conversation. It is flagged as a warning rather than an error, because the file will still upload; it just will not teach what you intended.
Duplicates and other quiet problems
- Duplicate records over-weight whatever they teach, and usually indicate a retry loop or a join that fanned out. Detection compares the serialised record, so two records with identical data but different key order are not treated as duplicates.
- A record that is not a JSON object — a bare string or array on its own line — is valid JSON but not a valid training example.
- An unrecognised role value is one of the most common schema errors, often from a pipeline that emitted "bot" or "human" instead of "assistant" and "user".
- A message missing content entirely is only acceptable when it carries tool calls instead; otherwise it is an error.
Validation is local
Training data is frequently the most sensitive material a team handles — support transcripts, internal documentation, customer records. Everything here runs in your browser and nothing is transmitted, which is the only sane property for a tool you would paste a real dataset into.