Short answer: The safest default is architectural: keep document contents in a local tool, inspect only the data you need and redact before anything leaves your device.

Key points

• Classify the payload before opening it in a third-party service.
• Prefer tools whose core workflow does not require an upload or public share URL.
• Copy a minimal, redacted excerpt instead of sharing the complete document.

Formatting is not the risky part

Pretty-printing JSON is mechanically simple. The risk comes from where the payload goes, what the service records and what happens when somebody presses Save or Share.

Production responses routinely contain bearer tokens, email addresses, account identifiers, internal hostnames, feature flags and support context. None of those fields need to be obviously labelled as secrets to be sensitive.

Some web tools process JSON entirely in the browser. Others offer server-backed sharing, analytics or URL import. The right question is therefore not “is it a website?” but “does this particular workflow send or retain my document?”

Use a local inspection workflow

A local-first workflow begins with the raw payload and keeps the working copy on the device. Open the file or paste the response, choose the view that matches the shape, make temporary edits and copy only the result you need.

For an array of records, a table is often faster than a deeply expanded tree. For a single response, search and a selected-value inspector are usually enough. Raw view remains useful when exact whitespace, ordering or parser behaviour matters.

• Open the payload locally from a file, paste action or raw browser page.
• Search for the field involved in the bug rather than expanding everything.
• Edit a scalar locally when you need to test a hypothesis.
• Copy a value, subtree or exact path instead of the entire response.
• Use redacted copy before moving evidence into a ticket, chat or document.

Redaction is a reduction step, not a guarantee

Automatic redaction can mask common secret-shaped fields such as authorization headers, API keys and tokens. It cannot understand every business-specific identifier or every value that becomes sensitive in context.

Always review the output. A useful rule is to remove whole branches that are irrelevant to the conversation, then redact the smaller excerpt. Data minimisation is more reliable than asking a pattern matcher to understand the complete document.

Where Blobster fits

Blobster is a browser workbench for this local step. The extension has no account, document upload, analytics, telemetry, cloud sync or public paste URL. It supports tree, table and raw views, local edits, path copy and redacted copy.

That does not remove the need to understand your organisation’s handling rules. It gives the debugging workflow a safer default: the document stays local unless you deliberately copy something out.

Sources

• Blobster privacy policy
• Blobster private JSON formatter workflow

Originally published by Mochavi. Blobster is a local-first browser workbench for structured developer data.

Short answer: Capture the smallest useful window, inspect the HAR locally, remove unrelated requests and copy a redacted request or excerpt whenever the full archive is unnecessary.

Key points

• A HAR may contain sensitive data even when it was created only for performance debugging.
• Browser export options reduce some fields, but they do not replace a review.
• Most support questions need one request or a short sequence, not the whole session.

What a HAR can contain

The HTTP Archive format records network activity. Depending on the browser, export option and application, it can include request and response headers, cookies, query parameters, post data, response bodies, internal URLs and timing information.

Chrome DevTools distinguishes a sanitised export from an export that includes sensitive data. That is useful, but “sanitised” is not the same as “safe for every recipient”. Application identifiers, URL paths and response bodies may still reveal more than the support case requires.

Capture less before redacting more

Start a fresh capture immediately before reproducing the problem and stop it as soon as the relevant request completes. A smaller archive is easier to understand and creates less accidental exposure.

If the issue can be demonstrated with one failed request and its preceding authentication or redirect step, share that sequence instead of several minutes of unrelated browsing.

• Close unrelated tabs and clear the network log.
• Reproduce one scenario with test data where possible.
• Stop recording immediately after the failure.
• Inspect domains, request paths, headers, cookies and bodies.
• Remove requests that do not contribute to the explanation.

Review the evidence locally

A request-list view makes the archive easier to scan than raw JSON. Filter by method, domain, status or a recognisable path, then inspect the selected entry in detail.

Look for authorization values, session cookies, signed URLs, personal data, request payloads, response bodies and internal infrastructure names. Query parameters deserve the same attention as headers.

Prefer an excerpt when it answers the question

A support engineer may need the method, URL shape, status, timing and a few response fields. They often do not need the full cookie jar or every response body in the session.

Blobster opens HAR files locally, keeps the tree and raw document available, and can copy a redacted HAR, request JSON, response excerpt or cURL representation. Automatic redaction is a starting point; review the copied output before sending it.

Sources

• Chrome DevTools network reference: save all requests as HAR
• Blobster local HAR viewer

Originally published by Mochavi. Blobster is a local-first browser workbench for structured developer data.

Short answer: Parse NDJSON line by line. Keep valid records available, report malformed lines separately and use table search when the records have a consistent object shape.

Key points

• NDJSON and JSONL contain independent JSON values separated by newlines.
• The complete file is not one JSON array and should not be parsed as one.
• Line-level errors let you repair a bad record without losing the rest of the dataset.

Why a normal JSON parser rejects the file

A JSON document has one top-level value. NDJSON deliberately places another complete JSON value on each line. The format is convenient for logs, streaming pipelines and append-only exports, but the full text is not a valid JSON array.

Pasting NDJSON into a conventional JSON formatter often produces an error after the first line. That error describes the parser mismatch, not necessarily a broken dataset.

Three independent records

{"time":"2026-07-28T09:00:00Z","status":200}
{"time":"2026-07-28T09:00:01Z","status":503}
{"time":"2026-07-28T09:00:02Z","status":200}

Keep valid records around a bad line

Line-delimited parsing creates a useful failure boundary. If line 417 is malformed, lines 1 through 416 and 418 onward can still be inspected. The viewer should report the line number and preserve the original source so the record can be corrected.

This matters for incident logs and bulk exports, where throwing away every valid record because of one truncated write is usually the least helpful behaviour.

Choose table or tree by shape

An object-per-line dataset with recurring fields maps naturally to a table. Columns make status codes, timestamps and identifiers easy to scan and filter. Records with highly variable or deeply nested structures are usually clearer in a tree.

Keep raw source nearby in both cases. A table is a projection of the records; it should not conceal malformed lines or imply that every object has the same schema.

A practical NDJSON debugging loop

Blobster detects NDJSON and JSONL, shows object-like records as a table where practical and keeps invalid lines separate from valid rows. The document remains local, including edits and copied subsets.

• Open the .ndjson or .jsonl file locally.
• Confirm record count and review any invalid-line summary.
• Filter by the field involved in the incident.
• Open the matching record in tree or raw form.
• Copy only the relevant row or a redacted subset.

Sources

• NDJSON specification
• Blobster NDJSON viewer

Originally published by Mochavi. Blobster is a local-first browser workbench for structured developer data.

Short answer: Use JSONPath for standardised JSON selection, jq when the path belongs in a command-line transformation, and JavaScript property access when the destination is application code.

Key points

• The same selected value can be represented in several path syntaxes.
• Keys with punctuation or spaces require bracket or quoted notation.
• Copying from the tree avoids transcription errors in long paths.

One value, three destinations

Suppose an API response contains an email under the first user’s profile. A support note, a shell command and frontend code may all refer to the same value, but each context expects different syntax.

Example document

{
  "users": [
    {
      "profile": {
        "email": "ada@example.test"
      }
    }
  ]
}

JSONPath selects values

JSONPath is standardised in RFC 9535. It begins at the root with $ and can select object members, array elements, slices and filtered descendants. It is useful in test tools, API clients and systems that explicitly accept JSONPath.

A simple copied path identifies one value. More advanced JSONPath expressions can select several values, so do not assume every expression behaves like a unique object address.

jq is a processing language

jq paths often resemble JSONPath after the root marker, but jq is a complete command-line processing language. The path may be the first step in a filter, projection or transformation.

Use the copied jq path as a reliable starting point, then add the operation the script needs. For example, .users[].profile.email streams the email value for each user.

JavaScript paths belong in code

Optional chaining is useful when application code must tolerate a missing intermediate value. It returns undefined instead of throwing when an optional access encounters null or undefined.

Keys that are not valid JavaScript identifiers need bracket notation. A key named feature.flag becomes data?.["feature.flag"], not data?.feature.flag.

Copy from selection instead of retyping

Long paths are easy to mistype, especially around array indexes and keys that need quoting. Blobster lets you select a tree node, table cell or search result and copy JSONPath, jq or JavaScript syntax from the same inspector.

The copied path describes the current document. If the schema is unstable or an array order changes, verify that an index-based path is still the right reference.

Sources

• RFC 9535: JSONPath
• jq manual
• MDN: optional chaining

Originally published by Mochavi. Blobster is a local-first browser workbench for structured developer data.

Short answer: Choose JSON Hero for its polished JSON exploration, related-value analysis, inferred schema and shareable web workflow. Choose Blobster when the document should remain in a local extension and the job includes edits, redaction, path copy or non-JSON formats.

Key points

• JSON Hero is open source and can be self-hosted.
• Its public product emphasises exploration, schema inference and sharing.
• Blobster deliberately has no account, telemetry or public document URL.

At a glance

Where JSON Hero is stronger

JSON Hero has a distinctive visual exploration experience. Its public product highlights fuzzy search, related values at the same path, inferred JSON Schema, code view, keyboard navigation and links that can open a document at a specific location.

It is also open source. A team that wants the JSON Hero interaction model without using the public host can evaluate and run the project itself. That is materially different from a closed hosted formatter.

Where Blobster is different

Blobster is installed as a browser workbench and is intentionally not a document-sharing service. It opens files, pasted text and raw structured pages locally. There is no public paste URL, document account, analytics or telemetry in the extension.

The product is broader than JSON exploration. It supports table and raw editing where appropriate, redacted copy, exact path copy and specialised views for formats such as NDJSON, JWT and HAR.

The privacy comparison needs nuance

“Web app” does not automatically mean “uploads documents”, and “extension” does not automatically mean “private”. Evaluate actual architecture and policy.

JSON Hero’s current privacy notice says the hosted service collects technical and usage information such as IP address, browser characteristics and activity for operation and analytics. Blobster’s extension does not include analytics or telemetry and has no server-backed document workflow. Self-hosting JSON Hero changes the comparison because the operator controls that deployment.

A simple decision rule

Use JSON Hero when you want a polished JSON-specific explorer, schema inference or a link-based collaboration flow. Use Blobster when you want a local inspection and editing surface across several developer formats and do not want a public sharing feature.

Neither product replaces jq for scripted transformations or a schema validator for formal validation. The right choice depends on the work immediately after the JSON is opened.

Sources

• JSON Hero product page
• JSON Hero privacy notice
• Blobster product page
• Blobster privacy policy

Originally published by Mochavi. Blobster is a local-first browser workbench for structured developer data.

Short answer: Choose JSONLint when the main question is whether JSON is valid or how to repair it. Choose Blobster when valid data needs deeper local inspection, table or tree editing, path copy, redaction or support for other developer formats.

Key points

• JSONLint says JSON validation happens client-side.
• Its site provides dedicated validation, repair, schema and conversion tools.
• Blobster focuses on an ongoing local workbench rather than a single validation form.

At a glance

Where JSONLint is stronger

JSONLint is direct. Paste JSON into the editor and validate or format it. Its current tool collection also includes repair, error analysis, schema validation, schema generation, sorting, escaping, minifying and conversion utilities.

That focus is valuable when syntax is the problem. A dedicated repair or error explanation tool can be faster than opening a larger workbench.

Where Blobster is different

Blobster begins after “is this valid JSON?” and treats the payload as a document to investigate. Search keys and values, move between tree, table and raw views, edit local values, copy an exact path and redact a subset before sharing.

It also handles formats that are adjacent to JSON debugging: NDJSON and JSONL logs, HAR captures, JWTs, YAML, TOML, XML, CSV, TSV, Markdown, .env, OpenAPI and FIX messages.

Both can process JSON locally

An honest comparison should not claim that every browser formatter uploads pasted data. JSONLint’s privacy policy explicitly says validation happens client-side and JSON content is not sent to its servers for processing.

The surrounding product still differs. The same policy describes Google Analytics and advertising cookies. Blobster’s extension has no analytics, telemetry, account or advertising layer. Decide whether that distinction matters for your environment.

Use both when the jobs differ

JSONLint can be the quicker answer for a malformed snippet or schema question. Blobster can be the better surface for a complete response, log, table or archive that needs investigation and selective sharing.

Tools do not need identical feature lists to compete for the same first action. Define the question first: validate the syntax, or work with the data?

Sources

• JSONLint editor
• JSONLint tools
• JSONLint privacy policy
• Blobster product page

Originally published by Mochavi. Blobster is a local-first browser workbench for structured developer data.