Why device-side bytes matter

Image compression is not only a visual-quality decision. In an upload product, it is a boundary that determines how many bytes leave the device and how many app-owned image files remain while work is queued, retried, completed, or cancelled.

📈 Market context

Ericsson reports a global average of 22 GB of mobile data traffic per active smartphone per month at the end of 2025 and forecasts mobile data traffic, excluding fixed wireless access, to reach 328 EB per month in 2031. Read the traffic forecast and its regional caveats.

Those figures explain why byte-intensive mobile paths deserve attention. They do not prove how much this package—or any particular application—will save. Product impact must be calculated from accepted outputs and measured in the host application's real upload and storage lifecycle.

💸 Two cost surfaces

📤 Bytes that move

An oversized source can pass through several stages:

device source → first upload → retry → API handling → server transform → storage

Server-side compression can reduce later storage or delivery bytes, but it cannot undo the first device-to-server transfer. The directly observable device-side quantity is:

source-to-output byte difference = package input bytes − accepted output bytes

A positive value means the accepted output is smaller; a negative value means it is larger. Keep that sign instead of hiding output growth by flooring the difference at zero.

Use accepted output rather than every generated result. An application may reject a result because it misses its byte limit, dimensions, visual-quality policy, format requirement, or another product constraint.

This delta is not automatically the application's incremental saving. The package input may already have been resized or transcoded by a picker or an existing upload pipeline. A matched baseline is required for that claim:

incremental transferred-byte reduction
  = current-pipeline transferred bytes − new-pipeline transferred bytes

Measure both sides over comparable accepted uploads, including bytes sent by partial or repeated attempts. Use prevented upload bytes only when that counterfactual has actually been established.

📱 App-owned bytes at rest

Mobile applications commonly create or retain their own image files while an upload is pending:

durable upload queue + package outputs + thumbnails/caches + stale residual files

The useful quantity is a snapshot of distinct files, without counting one file in more than one category:

app-owned image footprint = queue + outputs + caches + residual files

This is deliberately narrower than total phone storage. Ownership creates two different cases:

• A gallery or provider-owned source remains unchanged. Compression creates a new cache output, so peak storage can increase until the owned output is removed.
• An app-owned staging source may be replaced by an accepted output only when the application's retention policy permits deleting that staging file.

🧭 What the package controls

Boundary	Package contract	Product effect to measure
Output bytes	maxBytes searches JPEG or available WebP candidates and reports originalByteSize and byteSize	Accepted source-to-output delta; incremental transfer change is measured against the current pipeline
Runtime support	getImageCompressionCapabilities() reports formats, policies, concurrency, and resource limits	Fewer requests that fail after selection or user work
Native work	Decode downsampling, source and working-pixel limits, bounded concurrency, and cancellation	Planned work, latency, memory, and cancellation behavior on target devices
Transactional files	Failed and cancelled jobs remove partial work; success publishes one verified output	Residual files after failure or cancellation
Output ownership	removeCompressionOutput(uri) accepts only a package-owned cache output	Output reclamation after upload, copy, or explicit abandonment
Metadata	preserve, safe, and strip are explicit policies	Whether accepted outputs meet the application's privacy policy

The public API reference defines the exact return values, errors, and ownership rules. The output-files guide explains what remains the host application's responsibility.

🧮 Calculate a bounded scenario

The local-only calculator below keeps its inputs in browser memory. It reports the package input/output observation separately from a matched current-pipeline baseline, and it enables the staging-replacement result only when the application owns that source. Its byte-storage estimate does not price object, request, delivery, or transformation counts.

Local scenario calculator

Separate the byte boundaries

Change the assumptions below to inspect each quantity independently. This calculator does not transmit or persist your inputs; values stay in this page's browser memory and reset on refresh.

Accepted output count Package input bytes / accepted image Accepted output bytes / accepted image Matched current-pipeline transfer / accepted image Leave blank unless the cohort and acceptance policy are comparable. Retention days Byte storage price · USD / decimal GB-month App owns the staging source and may replace or delete it

Scenario resultsDecimal bytes · 30-day month

Source → accepted output3.5 TB less

Signed package input/output difference: positive means fewer bytes and negative means growth. This is not an incremental transfer claim.

Matched transfer difference Baseline required

Baseline transfer minus one full accepted-output transfer. Include partial and retry bytes in both measured paths before reporting a real product effect.

App-owned staging replacementNot applicable

Gallery/provider source remains. The generated output adds 500 GB until the app removes it.

Retained accepted outputs500 GB

$7.50 for the entered retention and byte-storage rate.

Count-priced object and request costsUnchanged, not zero

1,000,000 objects and 1,000,000 assumed writes in either scenario. Delivery, transformations, requests, free tiers, tax, and discounts are not priced here.

Calculation assumptions and date boundary

• Per-image byte values are scenario averages across accepted outputs.
• The new transfer path assumes one complete accepted-output upload. If it retries or partially transfers, use measured bytes for both paths.
• Storage is prorated over a 30-day month with 1 decimal GB equal to 1,000,000,000 bytes and one retained output per accepted image.
• The sample $0.015 rate is an editable input, not a live quote. Pricing and model assumptions were last reviewed on 2026-08-13; replace it with the byte-priced rate that applies to your bill.

🧮 Illustrative scale

The following arithmetic uses decimal units and assumes every output meets the host application's acceptance policy.

Source-to-output example

1,000,000 images × (4 MB source − 0.5 MB output)
= 3,500,000 MB
= 3.5 TB source-to-output payload delta

This is also 350 MB per 100 accepted images. It represents fewer first-hop bytes only when the same 4 MB package inputs would otherwise have been uploaded. Retry behavior is intentionally not assumed: compare actual transferred bytes when the baseline and new pipeline have different retry or partial-transfer rates.

App-owned queue example

200 staged images × 4 MB   = 800 MB
200 accepted outputs × 0.5 MB = 100 MB
difference = 700 MB

This difference applies only when the application owns the staged originals and is permitted to replace or delete them. It does not apply to gallery sources, provider-owned content, or files the application must retain.

🧾 Provider price snapshot

The following scenario converts the same arithmetic into provider-specific storage cost. It is illustrative, not a package savings claim.

Assumptions: 1,000,000 accepted objects; 4,000,000 input bytes and 500,000 output bytes per object; one retained copy for a full 30-day month; unchanged object, request, delivery, and transformation counts; USD before tax; no enterprise discount, credits, replication, CDN, acceleration, or other account usage.

Provider surface	Published price used	4 MB objects	0.5 MB objects	Difference under these assumptions	What does not decrease
AWS S3 Standard, Seoul	$0.025 per binary GB-month for the first 50 TB	$93.13/month	$11.64/month	$81.49/month	Standard internet ingress is free; 1M PUT requests cost $4.50 in either case
Cloudflare R2 Standard	$0.015 per GB-month after the 10 GB-month free allowance	$59.85/month	$7.35/month	$52.50/month	Object and write-operation counts are unchanged; direct R2 egress is free
Cloudflare Images storage	$5 per 100,000 stored images per month	$50/month	$50/month	$0/month	Stored, delivered, and transformed-image charges are count-based

The AWS rates come from the S3 Seoul public price list published August 7, 2026. AWS defines S3 storage GB as 2^30 bytes and lists standard internet ingress as free on the S3 pricing page. Cloudflare's R2 pricing, updated August 7, 2026, also rounds usage to billing units and shares its free allowance across account usage. Cloudflare Images pricing, updated July 8, 2026, charges by stored, delivered, or uniquely transformed image rather than source byte size.

Prices, free allowances, regions, and delivery paths change. Recalculate from the provider bill that applies to the application. Smaller retained objects can also reduce metered downstream delivery bytes, but that effect is not included above: it is zero for direct R2 egress and depends on CDN, region, free tier, cache, and delivery count elsewhere.

♻️ Upload, then release the output

removeCompressionOutput(uri) in this example belongs to the 0.4.1 source candidate and is not available in npm 0.4.0. The host application must use its own file API for successful-output cleanup until the candidate ships.

import {
  compressImage,
  removeCompressionOutput,
} from 'react-native-image-compression-kit';

const maxUploadBytes = 500_000;

const result = await compressImage({
  source: { uri: localImageUri },
  resize: { maxWidth: 2048, maxHeight: 2048, mode: 'contain' },
  output: { format: 'jpeg', quality: 90, maxBytes: maxUploadBytes },
  metadata: 'safe',
});

try {
  if (result.byteSize > maxUploadBytes) {
    throw new Error('Image did not meet the upload policy');
  }

  const sourceToOutputByteDelta =
    result.originalByteSize - result.byteSize;

  await upload(result.uri, { sourceToOutputByteDelta });
} finally {
  await removeCompressionOutput(result.uri);
}

maxBytes is a target-search contract, not a guarantee that every source can reach the requested size. The native operation returns the smallest generated candidate when the target is unreachable. Apply the host application's acceptance policy before counting the source-to-output delta or uploading the result. Report incremental transfer reduction only after comparing the bytes sent by a matched current-pipeline baseline.

📊 Measurement plan

Metric	Definition	Why it matters
Accepted-output rate	Accepted results ÷ completed compression results	Prevents counting unusable outputs as savings
Accepted source-to-output byte difference	Sum of originalByteSize − byteSize for accepted outputs, retaining negative growth	Measures the package input/output difference without inventing a baseline
Incremental transferred bytes	Current-pipeline bytes − new-pipeline bytes for comparable accepted uploads	Measures the counterfactual transfer effect, including retry and partial-attempt behavior
Retry bytes	Bytes transferred by repeated or partial upload attempts	Shows whether smaller payloads change the retry surface in the real network path
Upload latency p50/p95	Selection-to-server-acceptance time, reported separately from compression time	Separates device work from network effects
App-owned queue footprint	Distinct durable queue + generated output + cache + residual files at one snapshot	Measures storage under the host application's control without double counting
Output reclamation rate	Package outputs removed after upload or abandonment ÷ removable outputs	Detects successful outputs retained longer than policy allows
Failure/cancellation residuals	Partial files remaining after failed or cancelled jobs	Should remain zero for the package-owned work boundary
Compression latency and memory	Per-device p50/p95 duration and peak memory with source dimensions recorded	Guards against trading network bytes for unacceptable device cost

Segment results by platform, OS version, device class, source format, dimensions, network type, and acceptance policy. Do not compare Android and iOS fixture ratios unless their inputs and execution conditions are actually the same.

🛡️ Honest limits

• It does not claim that every image becomes smaller.
• It does not convert bytes into cloud savings without the host's actual price model.
• It does not treat a source-to-output byte delta as an incremental transfer reduction without a comparable current-pipeline baseline.
• It does not claim lower total phone storage while gallery sources remain.
• It does not treat planned decoded-pixel reduction as measured peak memory.
• It does not generalize two native fixtures into a cross-device success rate.

Use the product evidence page for measured package fixtures and their interpretation limits. Use this guide to define the product metrics that must be captured in a real application.