Canvas Memory Budgets for Long Screenshots: Why Limits Change by Device

A 1,000 × 20,000 screenshot contains 20 million pixels. In an uncompressed RGBA Canvas, the raw pixel buffer alone is roughly 80 million bytes before temporary canvases, decoded source images, undo snapshots, PDF data, and browser overhead are counted. File size on disk is therefore a poor estimate of editing memory.

Screenshot PDF version 0.0.13 uses device-aware pixel and history budgets to reduce crashes on lower-memory systems while retaining more detail and undo capacity on stronger devices. This article explains those current values and the reasoning users can apply to any browser-based image workflow.

Pixels, not compressed megabytes, drive Canvas cost

PNG and JPEG compress repeated or predictable visual information. A 4 MB PNG can expand into a much larger pixel buffer after decoding. The first calculation for a screenshot is:

pixel area = width × height

A rough lower-bound buffer estimate is:

RGBA bytes = width × height × 4

At 32 million pixels, one raw buffer is about 128 MB. A browser operation may temporarily hold the decoded image, destination Canvas, cropped Canvas, preview, and undo state at the same time. Actual memory use is implementation- and browser-dependent, so the formula is planning guidance rather than a promise.

Current Screenshot PDF pixel budgets

The editor reads the browser's navigator.deviceMemory hint when available and otherwise assumes a conservative middle value. Its Canvas pixel limits are:

| Reported device memory | Canvas pixel budget | | --- | ---: | | 2 GB or less | 20,000,000 | | Up to 4 GB | 32,000,000 | | Up to 8 GB | 48,000,000 | | More than 8 GB | 64,000,000 |

The browser value is coarse and not universally available. It should not be interpreted as a precise measurement of free RAM. The budget is a guardrail, not a benchmark score.

How oversized images are scaled

When an uploaded image exceeds the selected pixel budget, the editor computes a scale using the square root of the allowed-area ratio:

scale = √(pixel budget ÷ source pixel area)

Both width and height are multiplied by that scale. This preserves aspect ratio while reducing total area to the budget. For example, halving both dimensions reduces pixel area to one quarter.

Scaling prevents a single image from allocating an unbounded Canvas, but it also reduces source detail. Small interface text and thin lines should be inspected at 100 percent in the PDF preview. If they become difficult to read, divide the source into narrower or shorter sections instead of repeatedly increasing compression quality.

Annotation history has its own cost

Undo snapshots can duplicate a large Canvas. Screenshot PDF therefore adapts history depth:

• very large canvases or devices reporting 2 GB keep two snapshots;
• canvases above 12 million pixels or devices up to 4 GB keep three;
• typical mid-range cases keep four;
• devices reporting at least 8 GB can keep up to six.

Older object URLs are revoked when snapshots are evicted. This limits retained browser resources without altering the current document. Users should still export or save important work rather than treating undo history as persistent storage.

Dimensions can fail before total area

Browsers and graphics backends may impose maximum Canvas width or height in addition to total pixel area. Screenshot PDF's stitching path applies a separate maximum dimension before the area budget. Extremely narrow and tall images can hit a dimension boundary even when their total area appears reasonable.

Browser versions, GPU configuration, operating system, and available memory affect practical behavior. MDN's Canvas tutorial describes the API but does not provide one universal safe maximum for every environment.

Symptoms of memory pressure

• the image decodes but the preview remains blank;
• Canvas creation returns an unusable context;
• the browser tab reloads or becomes unresponsive;
• annotations become slow because snapshots are large;
• PDF generation fails while the original image still displays;
• the browser reports an out-of-memory or allocation error.

These symptoms do not automatically indicate a corrupted file. Reproduce with a smaller copy, close unrelated heavy tabs, and record source dimensions and device context.

Safer ways to handle very long material

1. Capture named sections with visible overlap.
2. Narrow the viewport so irrelevant sidebars are excluded, but ensure text remains readable.
3. Use the source service's official export when it preserves structure or metadata.
4. Avoid unnecessary repeated edits on a maximum-size Canvas.
5. Keep the original image until the PDF passes inspection.
6. Open the exported PDF in a second viewer before deleting any intermediate file.

For receipts, research, or support evidence, sectional files can be clearer than one enormous image. Use deterministic names such as part-01, part-02, and record the overlap or section boundaries.

A reproducible capacity report

When reporting a problem, include source width and height, compressed file size, browser and extension versions, reported device-memory tier if available, operation attempted, and the smallest dimensions that reproduce the failure. Do not attach private screenshots when a synthetic image can demonstrate the same allocation behavior.

Adaptive limits are not a claim that every device in a tier behaves identically. They are an explicit tradeoff between detail, stability, and undo capacity. Understanding the pixel math helps users choose a smaller, clearer capture before the browser reaches an unrecoverable limit.