API response capacity planner
API Response Size Calculator
Estimate response bytes, compressed transfer size, bandwidth per second, and limit risk from records returned, fields per record, field bytes, metadata envelope, pagination links, status headers, and request rate.
Response byte breakdown
Capacity pressure
| Format | Size behavior | Best fit | Watch carefully |
|---|---|---|---|
| Plain JSON | Baseline size with repeated keys and quoted strings | Public REST APIs, web apps, integrations | Large arrays repeat every field name per record. |
| HAL or JSON:API | Usually 10% to 35% larger than plain JSON | Hypermedia APIs with link-heavy clients | Embedded links and relationship objects grow quickly. |
| GraphQL JSON | Can be smaller when fields are selected, larger when nested deeply | Clients that need different field subsets | Nested edges, nodes, and duplicated fragments add bytes. |
| Protobuf | Often 35% to 75% smaller before compression | Internal APIs, mobile sync, service-to-service calls | Schema discipline and binary tooling are required. |
| CSV | Compact for flat tabular exports | Reports, bulk downloads, spreadsheet import | No nested metadata unless extra columns are added. |
| MessagePack | Smaller than JSON for numbers and repeated structure | Internal APIs needing flexible objects | Less inspectable in browser tools and logs. |
| Response pattern | Typical body size | Primary size driver | Planning note |
|---|---|---|---|
| Lookup detail | 2 KB to 80 KB | Nested children, audit fields, descriptions | Move rare detail fields behind expand parameters. |
| List page | 50 KB to 1 MB | Records returned and repeated field keys | Keep default page sizes conservative and sortable. |
| Search result | 100 KB to 3 MB | Highlights, snippets, facets, scores | Facet metadata can rival the hit list. |
| Metrics query | 200 KB to 10 MB | Series count and datapoints per series | Downsample before sending dense timelines to clients. |
| Bulk export page | 1 MB to 50 MB | Large pages and long text values | Prefer chunking, async jobs, or file download URLs. |
For weeks you design a set of API endpoints that is versioned, clean and documented. You deploy them and send them real traffic. But the latency still spikes. And it’s not because of the database query. Usually it’s something else. It is a large response full of wordy headers, many unnecessary field, and no compression. A quick lookup has become a network stall.
While developers pay attention to efficient code, few do when it comes to bytes being moved around the network. Use the calculator by entering record counts and field structures to let it handle math for you. You no longer have to guess about conversions and coefficients.
How to Make Your API Faster and Smaller
But biggest misconception about JSON is that it’s a lightweight format. When we’re returning arrays of several hundred records with two dozen fields per record, it’s anything but lightweight. Each object has to repeats all of its keys, adding extra bytes to every single row of our result set. Are there long string field names? Bloat happens fast. Half the stuff going across wire is duplicate metadata, and you probably didn’t realize you were sending data. That’s typically where people go wrong.
The calculator breaks out the pagination links and envelope around your actual record data, letting you see at a glance where fat resides. This all changes with compression but a lot of teams either ignore it entirely or think that their gateway will magically handle it. If your client doesn’t send an accept-encoding header or if your server are misconfigured, those 20% savings become zero. Actual transfer cost isn’t represented by raw bytes so the tool models that out explicitly.
Even little HTTP headers can be large when repeated on thousands of requests per second. Tracing baggage, cookies, and CORS policies adds up, causing what should of a tiny response to grow into a packet filled with headers. An admin data grid is different than a mobile feed. Compliance may require every audit field, whereas painting a screen only requires enough to do so.
These are different use cases that is shown by the tool’s presets. A lean edge API may trim fields aggressively, while a bulk export chunk will favor completion over speed. This means you must determine what tradeoff make sense for your particular endpoint. There isn’t one size fits all calculation here.
Most API gateways and serverless functions has a tight cap on the response size, which can be as small as six megabytes. Going over that doesn’t merely slow down your service. It breaks it. To help you avoid that, the calculator lets you enter an estimate of your (uncompressed) body size and compare it to typical limits. Before going into production, it tells you if a call might break under load. It is much better to find out that your search endpoint hits a limit while you still have time to fix it, rather than waiting until your site gets a surge in traffic.
Over time, this translates to bandwidth pressure. A couple more kilobytes per request doesn’t sound like much until it’s multiplied across tens of thousands of request every day. By showing both the per minute throughput and daily transfer volume, the tool converts ideas about payload size into concrete operational reality: how many list endpoints should I keep small? What fields should be compressed? How do I paginate before my limits bite me?
It’s all about understanding what you’re really measuring. Measure and then don’t guess. The bottlenecks will show themselfs.
