JSON Line Counter
Count physical JSONL rows and inspect syntax and UTF-8 sizes
Processed locally in the browser; input is not autosaved. Maximum input: 1 MiB.
Pasting or editing can normalize CRLF and lone CR to LF; byte counts then refer to text-area content. To inspect original file bytes, read a UTF-8 file and leave it unedited. A file BOM is retained for checking.
LF separates lines; CRLF is one separator. A final newline only terminates the previous line; consecutive newlines still create blank records. A lone CR does not split lines. Per-line UTF-8 sizes exclude separators.
JSON Lines disallows BOMs and blank records. Ignoring blanks only changes statistics, not source validity. Maximum 20,000 lines; per line, 64 levels and 20,000 structural markers. Over-limit lines are not fully checked. Numeric precision, duplicate keys, schemas and business rules are outside syntax checking.
Process again after changing input or options to generate a current result.
The full guide also includes pitfalls, worked examples, snippets, FAQs, and related tools for checking results or troubleshooting.
About this tool
Inspect line-delimited JSON before loading logs or an import fixture. The counter splits on LF, treats CRLF as one separator, and counts a final newline as a terminator rather than a new empty record. It reports physical lines, counted records, blank and ignored rows, JSON syntax outcomes, and minimum, mean and maximum UTF-8 line sizes without separators. Input byte totals include separators. Ignoring blanks changes the statistics but cannot make the original file conform to JSON Lines. Syntax checking accepts JSON scalars and does not certify number precision, duplicate-key semantics, schemas or business rules. Analysis runs locally on at most 1 MiB and 20,000 lines; input is not autosaved. Pasting or editing can normalize CRLF and lone CR to LF. For original byte counts, read a UTF-8 file and leave the text unedited; BOM bytes are retained.
Scenario Recipes
Locate a blank record before an import
Goal: Separate a terminal newline from a real empty record.
- Paste {"id":1}, an empty middle line, and {"id":2}, with one newline after the last record.
- Keep JSON syntax checking on and ignore-empty off. Confirm three physical lines, two valid records, one blank and minimum line size zero.
- Copy the original blank row or download the report. Remove that row in the source and recheck; a final newline may remain.
Result: The corrected source has two physical records and no blank JSON Lines record.
Production Snippets
A terminator is not another record
text
Input, shown with visible separators:
{"id":1}<CR><LF>
<LF>
"π"<LF>
Physical lines: 3
Valid JSON values: 2; blank lines: 1
Line bytes: 8, 0, 6
Record bytes: 14; separator bytes: 4; input bytes: 18Failure Clinic (Common Pitfalls)
The line count differs from newline count
Cause: A final newline terminates a record, whereas consecutive newlines create blank records.
Fix: Compare physical lines with the displayed separator convention instead of counting delimiter characters.
A huge numeric token passes
Cause: This is a syntax counter, not a decimal-preserving converter.
Fix: Use a suitable numeric parser and schema checks before consuming large IDs or exact decimals.
Validation was turned off
Cause: The tool measured bytes without parsing the values.
Fix: Treat the result as unchecked, and re-enable syntax validation before interpreting it as JSONL readiness.
Pasted byte counts differ from the file
Cause: Browsers can normalize CRLF and lone CR to LF in text areas.
Fix: Read the original UTF-8 file and keep it unedited for byte or newline comparisons. Editing switches to the normalized text-area content.
Frequently Asked Questions
Does a final newline count as an extra record?
No. {} followed by one LF is one record. Two consecutive LFs introduce a blank record. CRLF is one separator, while a lone CR does not split lines.
What do the byte sizes include?
Per-line sizes use UTF-8 and exclude LF or CRLF separators. Input bytes include all separators. An emoji such as π occupies four UTF-8 bytes but two UTF-16 code units. For original file bytes, use UTF-8 file input without editing. Pasting or editing can normalize CRLF and lone CR to LF.
Does ignoring blank lines make valid JSONL?
No. It excludes whitespace-only lines from record statistics and syntax counts. Their physical positions and blank count remain, and the source is not marked all-valid.
Does valid syntax guarantee safe numbers or unique keys?
No. Large numeric tokens such as 1e400 can be valid JSON syntax, and duplicate keys can parse. Numeric representability, key uniqueness, schema and application semantics require separate checks.
What happens to a BOM or very complex row?
A leading BOM on a row is diagnosed. Rows above 64 nesting levels or 20,000 structural markers are not fully checked; they are not reported as valid syntax.
Can I copy the exact invalid row?
Yes. Up to 100 diagnostics are shown with 200 code units of preview each. Row copy uses its complete original content, including an empty string for a blank row. Reports download locally; input is not autosaved.
Keep browsing