JSONL Viewer

What is JSONL and why it matters

JSONL (JSON Lines) is a format where each line is a valid JSON object. Also called newline-delimited JSON or NDJSON. Unlike regular JSON arrays, JSONL files don't need to be fully loaded into memory to process. You can stream them line by line, which makes them perfect for large datasets, logs, and data pipelines.

Each line in a JSONL file is independent. If one line has invalid JSON, the rest of the file is still readable. This fault tolerance is why JSONL is the standard format for machine learning datasets, API logs, database exports, and streaming data systems. Tools like Apache Kafka, Elasticsearch, and most data processing frameworks natively support JSONL.

The format looks like this: {"id": 1, "name": "Alice"} on line 1, {"id": 2, "name": "Bob"} on line 2, and so on. No commas between lines, no wrapping array brackets. Just one JSON object per line. This simplicity makes it easy to append new data, split files, and process in parallel.

When you need a JSONL viewer

Debugging API logs: Your backend logs API requests and responses in JSONL format. You need to quickly scan through thousands of log entries to find a specific error or trace a user's request flow. Opening the file in a text editor shows a wall of text. A JSONL viewer lets you expand individual lines, search by content, and filter by valid/invalid entries.

Inspecting ML training data: Machine learning datasets from Hugging Face, OpenAI, and other platforms use JSONL. You download a dataset with 50,000 training examples and need to spot-check the data quality, verify the schema, or find examples with specific attributes. A viewer with search and filtering makes this trivial.

Validating data exports: You exported data from a database or data warehouse in JSONL format. Before importing it into another system, you need to verify the structure, check for parsing errors, and ensure all required fields are present. The viewer shows you exactly which lines have issues and what the error is.

Reviewing streaming data: Your data pipeline produces JSONL files from Kafka, Kinesis, or other streaming systems. You need to inspect the output to verify transformations, check data quality, and debug processing issues. The viewer handles large files and lets you navigate through thousands of records efficiently.

How this viewer handles large JSONL files

The viewer processes file contents in your browser using JavaScript during normal tool use. Files under 10MB are usually quick; larger files depend on your device memory and browser limits.

Each line is parsed independently. If line 500 has invalid JSON, lines 1-499 and 501+ still display correctly. The viewer shows you exactly which lines failed to parse and what the error message is, and the line numbers it shows are the real line numbers in your file, so you can jump straight to the bad line in your editor. Blank lines are skipped but still counted. This is critical when working with real-world data that might have occasional malformed entries.

The max lines setting limits how many non-empty lines are parsed and rendered (10,000 by default). For a file with hundreds of thousands of lines, keeping it at 10,000 previews the first 10,000 entries and keeps the page responsive. The whole file is still read into memory before parsing, though, so multi-gigabyte files are better sampled first (for example with head -n 10000 file.jsonl).

Syntax highlighting uses Prism.js to colorize JSON keys, values, strings, and numbers. This makes nested objects much easier to read. You can toggle it off if you prefer plain text or if you're working with extremely large individual JSON objects where highlighting slows down rendering.

Working with files bigger than Max Lines

When a file has more non-empty lines than the Max Lines value, the viewer shows a notice such as "Only the first 10,000 of 250,000 non-empty lines are processed", and the valid/invalid counts, search, filters, and both downloads cover only those processed lines. Lines beyond the limit are not checked at all, so a clean result does not mean the rest of the file is clean. You can raise Max Lines in Options, but every processed line becomes a rendered item, so the page gets slower long before memory runs out.

For a file that is too big to work with comfortably, cut it down first and open the part you need. Because every line is a complete record, splitting by line count never breaks a record, and each piece is still valid JSONL:

# Preview: first 10,000 lines (the viewer's default Max Lines)
head -n 10000 big.jsonl > preview.jsonl

# Keep only the records you care about, still one per line
jq -c 'select(.level == "ERROR")' big.jsonl > errors.jsonl

# Split into 10,000-line files: part_aa, part_ab, ...
split -l 10000 big.jsonl part_

# Pretty-printed objects written back to back -> JSONL
jq -c . pretty.json > fixed.jsonl

# A JSON array -> JSONL (one item per line)
jq -c '.[]' array.json > fixed.jsonl

Note that jq stops at the first line it cannot parse. If the viewer has already reported invalid lines, either download the cleaned JSONL first or use a short Python script that skips bad lines and prints their line numbers:

import json

# Streams the file, so memory use stays flat on multi-GB files.
# Reports bad lines with real line numbers and keeps going.
with open("big.jsonl", encoding="utf-8-sig") as src, \
     open("errors.jsonl", "w", encoding="utf-8") as out:
    for line_no, line in enumerate(src, start=1):
        if not line.strip():
            continue
        try:
            record = json.loads(line)
        except json.JSONDecodeError as err:
            print(f"line {line_no}: {err}")
            continue
        if isinstance(record, dict) and record.get("level") == "ERROR":
            out.write(json.dumps(record, ensure_ascii=False) + "\n")

If you only need to look at a specific region of a huge file, for example the line number an import job complained about, the Large Text File Viewer reads the file in small chunks and can jump straight to a line without loading everything into memory. It shows raw text rather than formatted JSON, so copy the line you find back here to inspect it.

Search, filter, and export features

Search: Type any text to filter lines containing that text. Searches both the JSON content and error messages. Case-insensitive. Works instantly even with thousands of lines. Use it to find specific user IDs, error types, timestamps, or any other field value.

Filter by validity: Show only valid lines, only invalid lines, or all lines. When debugging data quality issues, filtering to invalid lines immediately shows you what's broken. When preparing data for import, filtering to valid lines shows you what will actually be processed.

Export to JSON array: Converts all valid JSONL lines into a standard JSON array format. Useful when you need to import the data into tools that expect JSON arrays instead of JSONL. The export includes only valid lines, automatically filtering out any parsing errors.

Download as JSONL: Downloads only the valid lines as a clean JSONL file, one record per line, with blank lines removed. If your original file had 1000 lines with 50 invalid entries, the download gives you a clean 950-line file ready to use (as long as Max Lines covers the whole file). This is how you clean up messy JSONL data before feeding it into production systems.

View modes explained

List view: Shows each line as a collapsible item. Click to expand and see the formatted JSON. This is the default and works best for most use cases. You get a quick overview of all lines with the ability to drill into specific entries. Line numbers help you reference specific records.

Grid view: Displays lines in a 2-column grid layout. Useful when you want to compare multiple entries side by side or when you're working on a large screen and want to see more data at once. Each card shows the line number, validity status, and expandable JSON content.

Raw view: Shows the original text of each line with no formatting or syntax highlighting, and it follows the current search and validity filter (blank lines are left out). Use it to read lines exactly as written or to spot stray characters. It renders faster than List or Grid because it draws one block of text instead of a card per line, but every line is still parsed when you load the file.

Common JSONL errors and how to fix them

Filter to invalid lines and compare the raw text with this table. The error message itself comes from your browser's JSON parser, so its wording differs between Chrome, Firefox, and Safari, but the cause is usually one of these:

If your file is really a regular JSON array rather than JSONL, convert it with the JSON to JSONL converter instead of fixing lines by hand. Going the other way, once the lines are clean the JSONL to JSON converter turns them into an array for tools that do not read JSONL, and if you want to scan records as rows and columns, open the downloaded JSON array in JSON to Table.

Common JSONL use cases in production

OpenAI fine-tuning datasets: OpenAI requires training data in JSONL format for fine-tuning GPT models. For chat models, each line is one example with a messages array of system, user, and assistant turns. Before uploading to OpenAI, you need to verify the format, check for encoding issues, and ensure all required fields are present. This viewer makes that validation trivial.

Elasticsearch bulk imports: Elasticsearch's bulk API uses JSONL for batch operations. Each line alternates between an action descriptor and the document to index. When preparing bulk imports, you need to verify the structure and catch any malformed lines before sending to Elasticsearch. Invalid lines cause the entire batch to fail.

BigQuery and data warehouse exports: Google BigQuery, Snowflake, and other data warehouses export query results as JSONL. When you export millions of rows, you get a JSONL file. Before importing into another system or processing with Python, you want to preview the schema and verify the data looks correct.

Application logs and monitoring: Modern logging systems like Fluentd, Logstash, and Vector output structured logs in JSONL. Each log entry is a JSON object with timestamp, level, message, and metadata. When debugging production issues, you need to quickly scan through logs, filter by error level, and search for specific events.

Privacy and security

Everything happens in your browser. Your JSONL file never gets uploaded to any server. The tool works after the page loads for normal tool processing. You can disconnect your internet, and it still functions. This is critical when working with sensitive data like user information, financial records, or proprietary datasets.

For normal viewer use, JSONL file contents are parsed locally in your browser instead of being uploaded for server-side processing. Site ads, analytics, and other third-party scripts may still load as described in the privacy policy, so review your own data-handling rules before opening sensitive files.

The viewer uses JavaScript and the Web File API. When you upload a file, it is read into browser memory; when you export or download, the file is generated client-side and saved to your downloads folder.