JSON Minifier: Minify JSON to One Line

What minifying JSON does

JSON has two kinds of whitespace. Whitespace inside a string is data and is kept exactly. Whitespace between tokens — the newlines and indentation a formatter adds, the space after a colon or comma — is insignificant: the grammar in RFC 8259 allows any amount of it, or none. Minifying removes all of the second kind, so { "a": 1, "b": 2 } becomes {"a":1,"b":2}. Both parse to the identical value.

This tool does it by parsing the input with JSON.parse and re-serializing with JSON.stringify and no spacing argument. A side effect is normalization: duplicate structural whitespace, odd line endings, and a trailing newline all disappear, and invalid JSON is rejected with an error rather than passed through.

Why minify

• Smaller payloads — an API response, a config blob embedded in an HTML page, or a message body sent through a queue is a few tens of percent smaller with no whitespace.
• Embedding — JSON that has to live on a single line, for example inside a shell variable, a CSV cell, a database column, or a data- attribute, must be minified to fit.
• Fewer bytes at rest — logs and stored documents that are never read by a person take less disk space compact.

Minifying is not obfuscation. Every key and value is still in plain sight; it only removes formatting.

JSON to one line: where a single line is required

Minified JSON is always one line, which is often the whole point rather than the byte saving:

• A value in a .env file, which cannot contain a real newline.
• curl --data '…' or an HTTPie argument on the command line.
• A single cell in a spreadsheet or CSV export, or a database column stored as text.
• A GitHub Actions with: input or a CI variable.
• A log line where each event must be one record.

If the destination needs the JSON inside quotes (a JSON string field, a shell or code string), use One line as escaped string. For a list of records that should be one per line (log ingestion, BigQuery, jq -c style), use Array to JSON Lines.

Worked example

{
  "name": "api",
  "ports": [ 80, 443 ],
  "tls": true
}

becomes {"name":"api","ports":[80,443],"tls":true}, and as an escaped string "{\"name\":\"api\",\"ports\":[80,443],\"tls\":true}".

What is kept and what is removed

Removed	Kept
Indentation and leading spaces	All string contents, exactly
Line breaks between keys	Key order
Space after : and ,	Every value and its type
Trailing whitespace	\n and \t escapes inside strings

How much you actually save

Input	Raw bytes	Minified	Gzip of minified
Pretty-printed, 2-space indent	100%	~55–80%	~15–25%
Pretty-printed, 4-space / tabs	100%	~45–70%	~15–25%
Already compact	100%	100%	~20–30%

The important row is the last column. Indentation is extremely repetitive, so gzip and brotli — which almost every server and CDN apply automatically — compress it away to almost nothing. Minifying a document that will be sent gzipped typically saves only a low single-digit percentage on the wire. Where minifying still clearly wins is anywhere compression is not in play: uncompressed responses, data pasted into another file, and size limits measured in raw characters.

When not to minify

Leave a file indented if a human reads or edits it: package.json, tsconfig.json, .eslintrc.json, CI pipelines, fixtures checked into version control. A minified file produces a one-line diff for every change and is painful to review. Keep the readable copy as the source of truth and minify only at build or send time.

Questions