JSON turns up in enough different roles that it is worth separating them: the format is the same everywhere, but what each use case actually needs from it differs, and confusing one for another is a common source of awkward decisions (adding comments to a machine-generated API payload, or expecting an NDJSON log pipeline to parse as one JSON document).
REST API payloads
The most common use case by volume. A request body and a response body are
each one JSON document, Content-Type: application/json, generated by one
side and consumed by the other with no human reading it in the middle.
Nothing here needs comments or hand-editing convenience; what it needs is
an unambiguous grammar every language parses the same way, which is JSON’s
actual strength. A REST payload is also the shape JSON Schema
Validator exists for: check a response
against the contract the API is supposed to honor, and see exactly which
field violates it and why, before that bug reaches production code that
assumes the field is there.
Application configuration
package.json, tsconfig.json, composer.json, and dozens of tool
configs besides. This is the one use case where JSON’s lack of comments
actually costs something: a setting with no explanation next to it, because
the format has nowhere to put one. Some tools work around this with a
// comment key nobody reads programmatically, others switch to YAML or a
JSON superset (JSON5, JSONC) that adds comments back in. See JSON vs
YAML for the fuller tradeoff; the short version is
that config files edited by hand often benefit from YAML’s comments, while
config generated and consumed entirely by tooling is fine as plain JSON.
NoSQL and document databases
MongoDB stores documents as BSON, a binary format that is a superset of JSON’s data model, and returns JSON (or a JSON-like shell syntax) when you query it. CouchDB and most document stores accept and return JSON directly. The appeal here is structural: a document database’s whole pitch is storing data in roughly the shape your application already uses it in, rather than normalizing it into rows and foreign keys first, and JSON’s object-and-array model is close enough to most languages’ native types that the translation is close to free.
Log lines and streaming data: NDJSON
A single JSON document does not stream well: a parser generally needs the whole thing before it can produce a value, since a document is only valid once its final closing brace arrives. Newline Delimited JSON (NDJSON) solves this by making each line its own complete, independent JSON value, so a log pipeline, a Kafka topic, or a large export can be processed one line at a time without holding the whole file in memory. The JSON to NDJSON Converter converts a JSON array into this line-per-record format and back, with recovery for a stream that has a malformed line partway through rather than failing the whole file over one bad record.
Browser storage
localStorage and sessionStorage only store strings; anything
structured goes in as JSON.stringify(value) and comes back out as
JSON.parse(stored). This is also where the number precision issue JSON
Data Types Explained covers becomes a real bug
rather than a curiosity: round-tripping a large integer ID through
localStorage via the browser’s own JSON.parse can silently change the
value, which is exactly the failure mode this site’s own tools are built
to avoid and report rather than reproduce.
Trying it with your own data
Every tool mentioned above runs entirely in your browser: nothing pasted into the JSON Formatter, the NDJSON converter, or the Schema Validator is ever uploaded anywhere, which matters most for exactly the kind of real API responses and config files this page is about.