Repair invalid JSONL rows without losing line identity
Keep the one-JSON-value-per-line contract and separate valid, malformed and empty lines by original line number. Put any repair candidate beside the source and review it before handoff.
The fixture numbers physical lines from 1. The extra text on line 2 and the empty line 3 stay distinct from the valid row on line 4.
Line
State
Diagnosis
Decision
1
Valid
valid JSON
Keep original
2
Invalid
Trailing content
Repair review
3
Empty
Not a JSON value
Do not export
4
Valid
valid JSON
Keep original
Review a candidate beside the source
Line 2 can show a candidate with the trailing text removed, but this guide does not decide that the candidate is correct. Hand off the original invalid line, diagnosis, candidate and reviewer together.
line 2 original: {"id":2,"name":"B"} trailing
line 2 candidate: {"id":2,"name":"B"}
decision: repair-review
This guide does not guarantee the receiver's schema, required fields or acceptance.
Review before handoff
Keep the source and number physical lines from 1.
Classify each line as valid, invalid or empty and record the reason.
Keep a candidate beside an invalid source line and mark it for review.
Do not silently discard invalid or empty lines; document every exclusion.
After approval, run the receiver's JSONL validation again.
This guide is static browser-local material. Input, files and validation results are not sent to or stored by an external service.
Do not treat invalid rows as success
If line numbers are compacted, the result can no longer be matched to the source log or a reprocessing result. Even when exporting only valid rows, record every excluded line and its reason first.