API Payload Analyzer: Understand Your JSON at a Glance
Before optimizing an API response, you need to know what's actually in it — how big it is, how deeply nested, how many fields, and where the bulk of the data lives. This tool walks your JSON payload recursively and reports exactly that, flagging common structural concerns (excessive depth, oversized arrays, large total size) along the way.
Byte size uses the browser's Blob API for a true UTF-8 byte count, not just character length.
Why Byte Size Isn't Just Character Count
A payload with emoji, accented characters, or other multi-byte UTF-8 sequences has a byte size larger than its character count — using the `Blob` API to measure gives the actual size that would be transferred over the wire or counted against a request-size limit.
Depth as a Design Smell
Deeply nested JSON (many levels of objects-within-objects-within-arrays) is harder for client code to navigate safely and often indicates the response mirrors an internal database schema too literally rather than presenting a client-friendly shape.
Spotting Pagination Candidates
The tool tracks which array in the payload has the most items and where it lives (by JSON path) — a large embedded array is the most common single reason an API response bloats past a reasonable size, and usually the first thing to paginate or lazy-load.
Practical Examples
Auditing a Response Before Optimization
Checking why an endpoint feels slow.
- 1.Paste the actual response JSON
- 2.Check size, depth, and largest-array findings
- 3.Identify what to trim or paginate
What Gets Measured
- Byte size (UTF-8, via Blob)
- Maximum nesting depth
- Total key count across all objects
- Object / array / null counts
- Per-type value counts (string, number, boolean, etc.)
Good Use Cases
- Diagnosing why an API response is large or slow
- Deciding whether an endpoint needs pagination
- Reviewing response shape complexity during API design
- Sanity-checking payload size before hitting a request-size limit
Frequently Asked Questions
How is byte size calculated?
Using the browser's `Blob` API on your exact input text — this gives the true UTF-8 byte size, which can differ from the character count for payloads containing non-ASCII characters.
What counts as 'nesting depth'?
The number of levels you'd need to traverse to reach the deepest value in the payload — a flat object is depth 1, an object containing an array of objects is depth 3, and so on.
Why does deep nesting get flagged?
Very deep nesting (roughly 6+ levels) often signals an over-normalized response shape that's awkward for API consumers to work with — most REST/GraphQL API design guides recommend flattening structures where reasonably possible.
Why does it flag large arrays specifically?
A single array with hundreds of items embedded directly in a response is a common signal that the endpoint should support pagination instead of returning everything in one payload — this affects both response time and client memory usage.
Is my payload sent anywhere?
No, all analysis happens locally in your browser.