Pixels, Megapixels and Browser Memory.

File size is not workspace size

A file on disk stores an encoded image. Opening it creates a representation the browser can draw and edit. The decoded representation can be much larger than the compressed file. A detailed photograph and a flat graphic with the same dimensions may have very different file sizes while requiring similarly sized basic pixel buffers.

An editor can hold more than the source buffer. Preview canvases, masks, temporary transforms and brush history add to memory use. The operating system and other tabs also need resources. This is why an image that uploads quickly is not necessarily inexpensive to process locally.

Worked example: an illustrative raster

A 4,000 × 3,000 image contains 12,000,000 pixels, or 12 megapixels. With the default byte-based RGBA representation described by MDN, a single buffer needs 4,000 × 3,000 × 4 bytes, which is 48,000,000 bytes. That calculation excludes the encoded source, mask, canvas implementation and any additional working copies.

If an operation needs another full-sized buffer, the total grows again. This example is a simple lower-level memory calculation, not a measurement of an entire browser process. Real memory use depends on implementation details and device behavior, so it should not be presented as a precise total for every editor.

Why the workspace has limits

Backdropless accepts up to 24,000,000 pixels and 10,000 pixels on either side. Those are product limits, not a guarantee that every device can comfortably process the maximum. The editor rejects an oversized source instead of silently shrinking it and then advertising the result as unchanged full resolution.

A narrow panoramic image can hit the side limit while remaining below the pixel-count cap. Both conditions matter. Check the actual width and height when a file is rejected rather than looking only at the megabyte value shown in the file browser.

Prepare a suitable working copy

If a source exceeds the workspace, preserve the original and make a smaller copy in a trusted local image application. Choose dimensions according to the actual destination need. Reducing an unnecessarily large source can be reasonable, but it should be a deliberate preparation step rather than a hidden change inside the removal workflow.

Do not enlarge a small source simply to meet a preferred maximum. More pixels do not automatically mean more useful detail. A sharp appropriately sized image is more valuable than an enlarged raster whose additional samples only interpolate the original blur.

Batch size adds another boundary

The app processes batch images sequentially, but encoded outputs accumulate for the ZIP. The ZIP workspace has its own cap, distinct from the dimensions of an individual source. A collection of valid images can therefore require separate batches even though every file works alone.

When troubleshooting, test the file individually and inspect the exact error. Distinguish an unsupported decoder, excessive dimensions and a batch archive limit. Those are different failures with different remedies. Repeatedly retrying the same oversized source does not change the memory required to decode it.