TL;DR / Summary: Multipart uploads work best when chunk byte counts are powers of two aligned with buffer sizes. Calculate 2^n bytes for candidate chunk sizes on tothepowerof2.com, then test one step up or down if retries spike.
Why APIs secretly love 2^n bytes
S3-compatible storage, resumable HTTP uploads, and CDN ingest pipelines read chunks into ring buffers sized at 4 KiB, 64 KiB, or 1 MiB internally. When your part size is already a power of two, client libraries avoid partial buffer flushes at the end of each read.
That does not mean decimal megabytes fail—it means starting at 2^n candidates reduces off-by-one friction when docs say “minimum part size 5 MiB except when…” and you are converting units mentally.
Building a candidate ladder
Try this ascending list for home broadband uploads:
- 2^18 bytes (256 KiB) — safe on memory-tight mobile browsers
- 2^20 bytes (1 MiB) — default sweet spot for many SDK examples
- 2^22 bytes (4 MiB) — better on fiber if latency is low
- 2^24 bytes (16 MiB) — watch RAM on low-end laptops
Compute each with the homepage tool so your config files use exact integers, not rounded decimals that truncate in JSON.
Mapping chunk size to link speed
Rough rule: pick a chunk you can upload in at least one RTT window without saturating retry buffers. On 20 Mbps uplink, 1 MiB parts take under a second—fine. On 1 Mbps rural uplink, 4 MiB parts increase pain when a failure forces retransmit of the whole part.
Measure empirically. Log three trials per size; powers of two give you discrete steps for A/B tests without arbitrary 3.7 MiB guesses.
Parallelism and 2^n part counts
Some clients cap concurrent parts at eight (2^3). If file size divided by chunk size yields a prime number of parts, you may underutilize parallelism. Nudge chunk size one power down until part count divides evenly across workers—or accept a slightly larger final part.
Checksum and crypto block alignment
Hashing libraries process 64-byte or 512-bit blocks internally. Chunk boundaries rarely need to match hash blocks, but encryption modes with chained IVs care about consistent part ordering. Document which 2^n size you standardized so teammates do not mix configs across environments.
When smaller beats bigger
Mobile Safari kills background tabs; huge chunks lose progress when users switch apps. Drop to 256 KiB or 512 KiB (2^18–2^19) even if desktop fiber tolerates 16 MiB. User experience beats theoretical throughput.
Spreadsheet column for DevOps
Keep a team wiki table: column A = exponent n, column B = byte count from the calculator, column C = observed p95 upload time. New hires inherit evidence instead of folklore.
Next deploy window
Before changing production multipart settings, recompute your three favorite 2^n sizes on the 2^n calculator, run a staging upload of a gigabyte test file, and ship the winner with metrics attached.
Resumable uploads after disconnect
Smaller 2^n chunks reduce bytes re-sent after Wi-Fi drops on trains. Larger chunks win on stable fiber. Mobile-first apps should default 2^18 or 2^19 unless telemetry proves otherwise.
Server-side minimum part rules
Cloud APIs publish minimum and maximum part sizes—often 5 MiB minimum except last part. When minimum is not a power of two, choose the smallest 2^n still above the floor, or use exact documented minimum if mandated. Never assume 1 MiB works because it worked on another vendor.
Cost accounting
Some providers bill per PUT request. Many small parts inflate request charges; fewer large parts inflate retry cost. Model both: requests × price + expected retry bandwidth. Powers of two simplify spreadsheet scenarios.
Testing checklist before production
Upload 10 GB test object with three chunk sizes, record p50 and p95 duration, error rate, and CPU on client. Pick winner, document exponent n in infrastructure repo README, link calculator for future interns.
Browser File API limits
Very old browsers cap blob slice sizes differently. If audience includes legacy enterprise browsers, test 2^20 vs 2^21 slices in QA matrix. Mobile WebKit tolerates large slices until memory pressure kills tab—telemetry beats assumptions.
Progress bars feel smoother with more parts; backend costs rise. Product managers pick UX vs infra tradeoff; engineers supply 2^n options table with measured costs.
Edge CDN ingest quirks
Some CDNs re-chunk upstream regardless of client part size. Your 2^n optimization at origin still helps first mile; last mile may re-split. Trace one upload with packet capture before declaring victory in postmortem.
Multipart abort cleanup
Failed uploads leave orphan parts billed until lifecycle rules abort incomplete multipart after N days. Smaller 2^n parts mean more orphan objects if clients crash—monitor incomplete upload metrics in bucket dashboard alongside chunk size experiments.
Document chosen chunk size in runbook so on-call engineers know expected part count when purging stuck uploads after incident.
Document the winning exponent in your client SDK config comment block so the next upgrade does not silently revert to vendor default part sizes that ignore your load testing.
