Skip to content
ZeroServer.tools

JSON Size Analyzer

Inspect, profile, and rank JSON keys and array structures by UTF-8 byte consumption.

Presets:
Type Filter:
Show:
(root)object900 B71.9%
(root).dataobject872 B69.6%
(root).data.usersarray828 B66.1%
(root).data.users[0]object504 B40.3%
(root).data.users[1]object321 B25.6%
(root).data.users[0].profileobject215 B17.2%
(root).data.users[0].activityLogarray156 B12.5%
(root).data.users[1].profileobject138 B11%
(root).data.users[0].profile.biostring122 B9.7%
(root).data.users[0].activityLog[1]object81 B6.5%
(root).data.users[0].activityLog[0]object72 B5.8%
(root).data.users[1].activityLogarray71 B5.7%
(root).data.users[1].activityLog[0]object69 B5.5%
(root).data.users[1].profile.biostring52 B4.2%
(root).data.users[0].profile.avatarstring44 B3.5%
(root).data.users[1].profile.avatarstring44 B3.5%
(root).data.users[0].emailstring27 B2.2%
(root).data.users[1].emailstring23 B1.8%
(root).data.users[0].activityLog[0].timestampstring22 B1.8%
(root).data.users[0].activityLog[1].timestampstring22 B1.8%
(root).data.users[1].activityLog[0].timestampstring22 B1.8%
(root).data.users[0].rolesarray21 B1.7%
(root).data.users[0].profile.locationstring19 B1.5%
(root).data.users[0].activityLog[1].actionstring16 B1.3%
(root).data.users[0].namestring15 B1.2%
(root).data.users[0].activityLog[0].ipstring13 B1%
(root).data.users[0].activityLog[1].ipstring13 B1%
(root).data.users[1].profile.locationstring12 B1%
(root).data.users[0].idstring11 B0.9%
(root).data.users[0].roles[1]string11 B0.9%
(root).data.users[1].idstring11 B0.9%
(root).data.users[1].namestring11 B0.9%
(root).data.users[1].activityLog[0].ipstring10 B0.8%
(root).statusstring9 B0.7%
(root).data.users[1].rolesarray8 B0.6%
(root).data.users[0].roles[0]string7 B0.6%
(root).data.users[0].activityLog[0].actionstring7 B0.6%
(root).data.users[1].activityLog[0].actionstring7 B0.6%
(root).data.users[1].roles[0]string6 B0.5%
(root).data.totalnumber3 B0.2%
(root).data.perPagenumber2 B0.2%
(root).data.pagenumber1 B0.1%

Total Size

1,252 B

Nodes Profiled

42

Root Node

object

Heaviest Key

(root).data (69.6%)

How JSON size profiling works

This utility recursively traverses JSON payloads and serializes individual sub-trees into UTF-8 strings to calculate exact byte footprints. It identifies bloated properties, redundant nested arrays, and oversized text fields that increase network payload sizes in REST or GraphQL APIs.

To view JSON in an expandable tree, use our JSON Tree Viewer. To format and clean JSON formatting, visit the JSON Formatter.

Built and maintained by Meet Shah · Last updated

What this tool is used for

  • Finding which keys account for most of a payload's bytes.
  • Deciding what to drop from an oversized response.
  • Checking whether an array or an object dominates a document.
  • Comparing two payloads on where their weight sits.
  • Producing evidence for a payload-reduction change.

Frequently Asked Questions

Why is my JSON payload so large?
Usually repeated keys. JSON stores every property name on every object, so an array of 10,000 records repeats each key 10,000 times — which is why compression helps so dramatically and why a columnar format helps more.
Does minifying JSON help much?
Before compression, yes — whitespace can be a fifth of a pretty-printed document. After gzip the difference is small, because compression removes exactly that kind of repetition.
What is the biggest saving available?
Sending less. Dropping fields the client does not use, paginating, and trimming null-valued keys usually beat any encoding change — and unlike compression, they also reduce parse time and memory.
How much does base64 data inflate a payload?
By a third, and it defeats compression on already-compressed content such as images. Embedding a file in JSON is convenient and is the most common reason a payload is unexpectedly enormous.
Are numbers smaller than strings?
Usually, since they avoid quotes and escaping — but large integers sent as numbers lose precision above 2^53, which is why many APIs send ids as strings and accept the extra bytes.

Common errors and gotchas

  • Optimising the largest key when the real cost is a repeated small one across many array items.
  • Measuring uncompressed size when the wire cost is after gzip, which changes the ranking.
  • Removing a field a client depends on, which the size analysis cannot tell you.
  • Assuming key names are negligible, when at scale they can be a large share of an array's bytes.
  • Comparing sizes across differently formatted documents, where whitespace dominates.

Related Developer Utilities tools

Private & free — this tool runs entirely in your browser.

IndieKitShip your Next.js startup in days.affiliate