How to minify json api payloads to reduce response size
- Step 1Grab a representative response body — Open your browser DevTools Network tab, click a JSON request, and copy the response body (or save it as a
.jsonfile). Pick a typical large endpoint — a list response or a deeply nested aggregate — rather than a tiny{"ok":true}, so the measured saving reflects your real traffic. - Step 2Drop the file or paste the JSON — Drag a
.jsonfile onto the dropzone above, or paste the body. Parsing happens locally in your browser. The tool accepts a single JSON document per run — if you copied a multi-line NDJSON log of separate objects, see the edge cases below. - Step 3Decide whether to also remove nulls — Leave Also remove null values unchecked to measure pure whitespace savings (the apples-to-apples comparison against your current serializer). Check it only if your API genuinely treats absent and
nullas equivalent — it permanently drops everynullproperty and null array element. - Step 4Minify and read the ratio — Click Minify JSON. The result strip shows
inputBytes → outputBytes · N% smaller. A pretty-printed payload typically shrinks 20–35%; a heavily 4-space-indented or deeply nested body can shrink more. If the saving is under ~10%, your source was probably already compact and minification is not your lever. - Step 5Compare against your current Content-Length — Put the minified
outputBytesnext to theContent-Lengthyour endpoint reports today. If they already match, your serializer is minifying; if your endpoint is much larger, you are shipping whitespace and minifying at the serializer (res.json(obj)in Express emits compact JSON by default) is a free win. - Step 6Copy or download the minified body — Use Copy to drop the single-line JSON into a test or request builder, or Download to save it as
<name>.min.json. For a deeper payload diet than whitespace, prune unused fields with json-key-filter — removing fields beats removing whitespace on large bodies.
What this tool does to an API payload
The minifier parses with JSON.parse(text.trim()) then re-serializes with JSON.stringify. Everything below is a consequence of that round-trip, verified against the implementation.
| Aspect | Behaviour | Why it matters for an API |
|---|---|---|
| Whitespace (spaces, tabs, newlines) | Removed entirely — between properties, around colons, between array elements | This is the saving you are measuring; typically 20–35% of a pretty-printed body |
| Key order | Preserved in object insertion order | ETag / cache-key stability: the same input produces the same byte-identical output |
| Duplicate keys | Collapsed — the last value wins ({"k":1,"k":2} → {"k":2}) | A malformed response with repeated keys is silently de-duplicated; verify the kept value is the intended one |
| Numbers | Normalised: 1.0 → 1, 1e3 → 1000, 0.10 → 0.1 | Cosmetic for most clients, but a strict consumer comparing raw strings will see a different (canonical) form |
| Large integers | Lose precision beyond 2^53 (12345678901234567890 → 12345678901234567000) | Snowflake IDs / bigint primary keys corrupt — see the edge cases; the fix is to transport them as strings upstream |
null values | Kept by default; removed (incl. null array elements) when Also remove null values is on | Lets you shrink sparse responses where most optional fields return null |
Minification vs the other levers for payload size
Minification is one of several techniques; ordered by typical impact on a JSON API response. Use this tool to measure (3); the others happen at the server or transport.
| Technique | Typical reduction | Where it happens | When to reach for it |
|---|---|---|---|
| Remove unused fields (BFF / sparse fieldsets) | Often 40–70% | Server / API design | Largest win on wide list responses; prune with json-key-filter then minify |
| Gzip / Brotli compression | 70–90% | Server or CDN edge | Always enable; eliminates repeated whitespace and keys |
| Minify (remove whitespace) | 20–35% | Serializer (this tool measures it) | Free at the serializer; also reduces client-side JSON.parse time |
| Binary formats (MessagePack, Protobuf) | Varies; large for numeric/repetitive data | Both ends | Very high-frequency or numeric-heavy APIs where JSON overhead dominates |
Cookbook
Real before/after payloads. The minified output is what JSON.stringify produces; the byte counts are illustrative UTF-8 sizes.
Pretty-printed list response → compact
ExampleA typical Express/Rails endpoint that was configured (or proxied) to pretty-print its output. Whitespace removal alone shaves roughly a third before any Gzip is applied.
Before (pretty, 1,184 bytes):
{
"users": [
{
"id": 1,
"name": "Ada",
"role": "admin"
},
{
"id": 2,
"name": "Lin",
"role": "user"
}
]
}
After (minified, 781 bytes · 34% smaller):
{"users":[{"id":1,"name":"Ada","role":"admin"},{"id":2,"name":"Lin","role":"user"}]}Sparse response with null padding
ExampleAn endpoint that emits every optional field as null. With Also remove null values checked, both the null properties and null array entries disappear — a large win on wide, mostly-empty rows.
Before:
{"id":42,"name":"Order","note":null,"coupon":null,"items":["sku-1",null,"sku-2"]}
After (removeNulls on):
{"id":42,"name":"Order","items":["sku-1","sku-2"]}
Note: this changes the shape. Only enable it if your client treats
absent and null identically.Catch a malformed response before it ships
ExampleBecause the tool parses before minifying, a body with a trailing comma fails here loudly instead of breaking a strict client. Fix the source, or run it through the format fixer first.
Input (trailing comma after last item):
{"items":["a","b",],"page":1}
Result: parse error — "Unexpected token ] in JSON".
The tool does not minify invalid JSON.
Fix non-standard JSON (trailing commas, comments, single quotes)
with json-format-fixer, then minify the cleaned output.Duplicate key from a hand-edited mock
ExampleA mock or fixture that accidentally repeats a key gets de-duplicated on the round-trip — last value wins. Useful to know when you minify a fixture and a field 'disappears'.
Input:
{"status":"ok","status":"error","code":500}
Minified:
{"status":"error","code":500}
The first status:ok was dropped. If that surprises you, your
source had a duplicate key — review which value is correct.Number normalisation on a metrics payload
ExampleMetrics endpoints often emit numbers in mixed forms. Minification canonicalises them, which is fine for numeric clients but worth noting if anything downstream compares the raw JSON string.
Before:
{"latency_ms":12.0,"rps":1e3,"error_rate":0.0100}
Minified:
{"latency_ms":12,"rps":1000,"error_rate":0.01}
Values are numerically identical; only the textual form changed.Errors and edge cases
Real errors and silent failures sourced from each platform's own documentation. Match the wording to the row, fix what the row says to fix.
NDJSON / JSONL log pasted as the payload
Parse errorThe tool parses the entire input as one JSON document with JSON.parse. A file with multiple top-level objects on separate lines (NDJSON / JSONL, common in API access logs and streaming responses) fails with 'Unexpected non-whitespace character after JSON'. .ndjson/.jsonl are accepted as file types but only when the file is a single JSON value. To compact an NDJSON stream, minify each line separately.
Large integer IDs beyond 2^53
Precision lossNumbers above Number.MAX_SAFE_INTEGER (9,007,199,254,740,991) lose precision on the round-trip: a Twitter/Discord-style snowflake 12345678901234567890 becomes 12345678901234567000. This is a JavaScript number limitation, not a whitespace operation. If your API carries 64-bit IDs, transport them as JSON strings ("id":"123...") so minification leaves them byte-exact.
Trailing comma or comment in the body
Parse errorStrict JSON forbids trailing commas, comments and single-quoted strings. A response captured from a lenient source (or a hand-edited mock) with {"a":1,} is rejected. Repair it first with json-format-fixer, then minify the result — the minifier intentionally only accepts valid JSON so it never 'guesses' at malformed input.
Already-minified response
ExpectedIf your serializer already emits compact JSON (Express res.json, most frameworks), the reported saving will be ~0% — the input and output bytes match. That is the confirmation you want: you are not shipping whitespace and minification is not your optimisation lever. Look at field pruning or compression instead.
Free-tier 2 MB file limit hit
Upgrade requiredFree accounts cap JSON input at 2 MB (2,000,000 bytes). A single large aggregate response over that triggers an upgrade prompt; Pro raises the ceiling to 100 MB. For measuring per-endpoint savings you rarely need a giant sample — a representative 100–500 KB body gives the same percentage.
Removing nulls changes the response contract
By designAlso remove null values is destructive: {"a":null} becomes {} and null array elements are dropped, shifting array length. Many clients distinguish 'field present and null' from 'field absent' (e.g. JSON Merge Patch semantics). Only enable this when absent and null are equivalent for every consumer of the endpoint.
Unicode escapes and non-ASCII characters
PreservedJSON.stringify keeps non-ASCII characters as literal UTF-8 (e.g. José, 日本語, emoji) rather than \uXXXX escapes, and preserves any \uXXXX already present in strings. Byte counts are measured in UTF-8, so multi-byte characters are counted accurately — the reported outputBytes matches the real over-the-wire size.
Comparing against Content-Length after Gzip
ExpectedThis tool reports uncompressed bytes. If your API serves Gzip/Brotli, the Content-Length on the wire is the compressed size and will be far smaller than outputBytes here. Compare like with like: measure minification gains uncompressed, and treat compression as a separate (and larger) layer on top.
Frequently asked questions
How much does minification actually help if I already have Gzip enabled?
With Gzip/Brotli on, the additional transfer saving from minifying the source is marginal — compression already eliminates repeated whitespace. The remaining benefit of minifying at the serializer is reduced client-side JSON.parse time (fewer characters to scan) and a smaller uncompressed body in places compression does not apply, such as in-memory caches or some logging pipelines. Use this tool to confirm the uncompressed delta before deciding it is worth a serializer change.
Does this change my data, or only the formatting?
It re-serializes the parsed value, so a few canonicalisations happen: whitespace is removed, duplicate keys collapse to the last value, and numbers normalise (1.0 → 1). Key order and all string values are preserved. The data is semantically identical for any standard JSON client. The one exception is the optional null-removal, which deliberately drops fields — leave it off if you want pure whitespace stripping.
Why did my big integer ID change after minifying?
JavaScript represents numbers as IEEE-754 doubles, which lose integer precision beyond 2^53. A 19-digit snowflake or bigint primary key gets rounded on the parse/serialize round-trip. This is unavoidable for numeric JSON in any JS engine. The fix is upstream: emit those IDs as JSON strings so they are never parsed as numbers.
Can I minify a whole NDJSON stream of API events?
Not in one pass — the tool parses the input as a single JSON document, and an NDJSON file has many top-level objects. Minify each line separately, or first combine the records into one JSON array (then each object is compacted as part of the array). The .ndjson/.jsonl extensions are accepted only when the file content is one valid JSON value.
What is the largest payload I can minify?
Free tier accepts up to 2 MB per file; Pro raises this to 100 MB. For measuring per-endpoint savings you do not need a huge sample — the percentage reduction is the same on a representative 100–500 KB body. Processing is in-memory in your browser, so very large files are bounded by available RAM.
Should I store JSON minified or pretty in my database?
Store it pretty (or however it reads best) — Postgres jsonb, for instance, parses to an internal binary form and does not retain your whitespace at all, so minifying before insert into a jsonb column saves nothing. Minify at the serialization boundary (the HTTP response), not at rest. For text columns where whitespace is stored verbatim, minifying does reduce storage.
Does the tool let me set indentation or sort keys?
No — this is a minifier, so the only output is whitespace-free. There is a single option, a checkbox to also remove null values. If you want indented output or alphabetically sorted keys, use the json-prettifier, which exposes indent width and a sort-keys option.
How do I get a bigger payload reduction than whitespace gives me?
Remove fields the client never reads. On wide list responses, dropping unused columns typically beats whitespace removal several times over. Prune the keys with json-key-filter, then minify the result here. Combine that with Gzip/Brotli at the edge and you reach the 80–90% reductions that minification alone cannot.
Will minifying break a client that expects null fields?
Only if you enable Also remove null values. Plain minification keeps every null exactly where it was. The null-removal option is for APIs where absent and null mean the same thing; if any consumer uses JSON Merge Patch semantics or checks hasOwnProperty, leave it off.
Is the reported percentage based on characters or bytes?
Bytes — UTF-8 bytes, the same unit as your HTTP Content-Length. The tool encodes input and output with TextEncoder before measuring, so a payload full of multi-byte characters (accents, CJK, emoji) reports the true on-the-wire size rather than an inflated character count.
Does minified JSON parse faster on the client?
Slightly — there are fewer characters for the parser to walk, so very large bodies show a measurable parse-time drop. The bigger client-side win is usually fewer fields (less object allocation) rather than less whitespace. Measure both; whitespace removal is the cheaper of the two to apply.
Is my API response data uploaded to JAD Apps?
No. Parsing and minification run entirely in your browser via the native JSON.parse/JSON.stringify engine. Response bodies — including user records, tokens and business data — never reach a JAD Apps server. The only thing recorded server-side for signed-in users is an anonymous run counter (file size and duration, no content).
Privacy first
Conversion runs locally in your browser. No file is uploaded — only metadata counters are saved for signed-in dashboard stats.