How to review a one-line JSON or XML file without damaging the evidence

Start with the source, not the formatter

When a production export opens as one enormous line, the tempting move is to paste it into the first formatter that looks convenient. That solves the visual problem before answering the more important questions: Is this JSON, JSON Lines, or XML? Is the source complete? Is it safe to upload? Will formatting preserve the meaning?

A useful rule is simple: the received file is evidence. Do not format it in place. Keep it read-only, note its byte size, and—when the provenance matters—record a SHA-256 hash. Work on a copy whose name makes the transformation obvious, such as orders.raw.json and orders.readable.json.

JSON, JSONL and XML are three different jobs

Extensions are clues, not proof. Confirm with a parser and check that it consumed the complete input. A formatter should never quietly “repair” a truncated document, discard a bad line, or invent a root element and then report success.

Validation and formatting answer different questions

Validation asks whether the input follows a grammar or schema. Formatting asks how to display a parsed structure. Pretty indentation cannot tell you whether an order matches your business schema, whether a timestamp is legitimate, or whether an identifier was clipped upstream.

JSON also has awkward edges. Duplicate object keys may be accepted differently by different parsers, and very large integers can lose precision when a tool converts them to a native floating-point number. If exact lexical values matter, compare the formatted output with a parser that preserves them.

XML needs extra restraint. In mixed content such as <p>Hello <em>world</em>!</p>, whitespace is part of the text model. Indenting every child node can change what a downstream consumer reads. Validate namespaces, encoding and mixed-content behavior before treating whitespace as cosmetic.

A repeatable six-step review

1. Preserve.Keep the original untouched. Record source, size and hash when the file may become audit or defect evidence.
2. Classify.Determine JSON, JSONL/NDJSON or XML from content and producer documentation—not the filename alone.
3. Validate.Use the correct local parser. Stop on truncation, trailing data, malformed records or XML errors; do not silently recover.
4. Format a copy.Write a new file. Keep the raw source beside it and name both clearly.
5. Review meaning.Search by stable identifiers, inspect types and counts, and separate presentation noise from real changes.
6. Hand off context.Share the validation command, tool/version, source hash and any known transformation—not just the pretty file.

Local commands are useful, but they still transform data

# Validate and create a separate JSON copy
jq . orders.raw.json > orders.readable.json

# Parse a JSON value stream; use a line-aware validator when one-record-per-line is contractual
jq -c . events.raw.jsonl > events.validated.jsonl

# Validate XML first, then format a separate copy
xmllint --noout document.raw.xml
xmllint --format document.raw.xml > document.readable.xml

Redirection protects the source filename, but it does not make a transformation lossless. Review numeric precision, character encoding, newline conventions and XML whitespace if another system will consume the derived copy.

Large files fail in memory, not only on disk

A 200 MB file does not imply a 200 MB working set. A tool may hold the source text, decoded strings, a parse tree, a formatted string and rendered UI at the same time. Full-document parsing can therefore require several times the file size and can freeze a browser tab or editor long before the machine runs out of disk space.

• Prefer streaming, line-by-line validation for JSONL.
• For large JSON arrays or XML documents, use streaming/SAX-style parsers or split at a documented structural boundary.
• Do not use an arbitrary byte split; it can cut through UTF-8 characters, strings or elements.
• Set a size ceiling before opening the file and keep enough free memory for a failed attempt to recover cleanly.

Where TailIQ Lens fits—and where it does not

TailIQ Lens is built by TailIQ, the publisher of this guide, so the relationship is explicit. Lens is one local browser-extension option for opening JSON, JSONL/NDJSON and XML, switching between source and tree views, searching, formatting and downloading a separate copy without sending the file to the TailIQ website.

It is meant for inspection and review. It does not replace a streaming pipeline, an XML schema validator, a version-controlled migration, or a purpose-built script for repeatable production transformations. If a command-line tool already fits the job, keep using it. The important part is the workflow: preserve, identify, validate, derive and document.

The short checklist

• Original file preserved and identifiable
• Actual format confirmed
• Validation completed before formatting
• Readable output saved as a separate artifact
• Upload and retention boundary understood
• Memory strategy chosen for the file size
• Tool, version and transformation recorded for handoff