Count JSONL records and detect invalid rows quickly
Quick CTA
Paste JSONL and inspect the line count plus invalid rows first; strict validation and preview settings stay in Deep.
Next step workflow
Deep expands pitfalls, recipes, snippets, FAQ, and related tools when you need troubleshooting or deeper follow-through.
JSON Line Counter is built for JSONL/NDJSON sanity checks before data import. Paste your line-delimited JSON data to count total rows, non-empty records, valid/invalid JSON lines, and byte-size distribution. The tool highlights invalid lines with line numbers so you can fix broken records before running ETL, ingestion, or log analytics pipelines. You can switch validation off when you only need quick counting. It is useful for data migration readiness, QA of generated logs, and preflight checks for bulk upload jobs. All analysis happens in your browser; no dataset is sent out.
Bad input: Treating every newline in NDJSON files as a valid object without trimming.
Failure: Ingestion KPIs look healthy while parser rejects a large tail of rows.
Fix: Count only non-empty valid JSON lines and report invalid-row ratio separately.
Bad input: Pasting multi-hundred-MB logs into UI for quick count during incident.
Failure: Tab freezes and operators lose temporary triage context.
Fix: Use streaming/CLI counting for large files and reserve UI for sampled validation.
Bad input: Multi-line formatted object counted as many records.
Failure: Pipeline volume metrics are inflated and alerting becomes noisy.
Fix: Detect NDJSON mode explicitly and reject pretty JSON in strict mode.
Bad input: Line count includes malformed JSON rows.
Failure: Count appears healthy but ingestion job fails later.
Fix: Pair counting with per-line JSON parse validation.
Bad input: Line counter includes whitespace-only rows in total.
Failure: Job sizing overestimates workload and wastes resources.
Fix: Validate each line as JSON object and skip empty lines explicitly.
Bad input: Blank lines and comments are counted as records.
Failure: Tool output appears acceptable but breaks during downstream consumption.
Fix: Normalize and validate inputs before running final conversion/check actions.
Bad input: Malformed JSON lines are silently included in totals.
Failure: Different environments produce inconsistent results from the same source.
Fix: Declare compatibility constraints and verify against an independent consumer.
Q01
Because JSONL workflows care about physical lines, blank-line policy, and approximate batch size during imports.
Q02
Yes. Some pipelines ignore them while others fail hard, so counting strategy changes the operational meaning.
Goal: Check how many line-level records you actually have before ETL or ingestion starts.
Result: You can catch missing records or inflated counts earlier in the pipeline.
Goal: Estimate record counts quickly before queueing downstream jobs.
Result: ETL scheduling becomes more predictable and balanced.
Goal: Validate key assumptions before results enter production workflows.
Result: Teams reduce rework and cut incident handoff friction.
Goal: Convert unstable incidents into repeatable diagnostics.
Result: Recovery speed improves and on-call variance decreases.
jsonl
{"id":1}
{"id":2}
{"id":3}Object count
Use it when you care about logical records in structured JSON.
Line count
Use it when operational import size depends on physical JSONL lines.
Note: Choose the metric that matches how the downstream system actually reads the data.
Raw lines
Use for quick file-size or rough ingestion estimates.
Logical objects
Use for NDJSON pipeline monitoring and record integrity checks.
Note: Operational metrics should track records, not only newline characters.
Loose counting
Use for exploratory cleanup on messy exports.
Strict NDJSON
Use for production ingestion gates.
Note: Strict validation prevents downstream parser failures during batch jobs.
Fast pass
Use when speed is prioritized and rollback cost is low.
Controlled workflow
Use for production, compliance, or shared operational outputs.
Note: JSON line counter is most reliable when paired with explicit acceptance checks.
One step
Use for local experiments and throwaway tests.
Stage + verify
Use when outputs affect downstream systems or customer data.
Note: Staged validation prevents silent drift from reaching production.
Recommend: Use strict JSONL validation with counts for valid, empty, and invalid lines.
Avoid: Avoid reporting only total lines when data quality is uncertain.
Recommend: Use quick in-browser counting to estimate record volume and shape.
Avoid: Avoid treating quick counts as schema or semantic quality guarantees.
Recommend: Use logical object count with strict parsing checks.
Avoid: Avoid relying on newline count alone.
Recommend: Start with loose counting, then switch to strict validation.
Avoid: Avoid enforcing strict mode before format normalization.
Recommend: Count validated records and track malformed line metrics.
Avoid: Avoid raw line-count assumptions on unvalidated files.
Recommend: Use fast pass with lightweight verification.
Avoid: Avoid promoting exploratory output directly to production artifacts.
Recommend: Use staged workflow with explicit validation records.
Avoid: Avoid one-step runs without replayable evidence.
Cause: Blank lines, malformed rows, or multiline records can break that assumption.
Fix: Define what counts as a valid line before using the metric operationally.
Cause: A formatted JSON document may span many lines but still represent only one object.
Fix: Use line counting only for true line-delimited workflows.
JSON Line Counter is most reliable with real inputs and scenario-driven decisions, especially around "ETL readiness checks before batch import".
It expects JSONL/NDJSON where each line is one independent JSON object or value.
Yes. Enable Ignore empty lines to skip blank rows from record counting and validation.
The tool returns line numbers and a preview of invalid rows so you can fix source files quickly.
Yes. Disable JSON validation to count records and byte-size stats without parsing each line.
Total lines includes every line break, while record lines exclude blank lines when ignore-empty is enabled.
No. Counting and validation run completely in your browser.