Export resolution, how far you can push the scale

Raising the export scale to 4x feels like it should give you four times the sharpness. It does not. Once you know what the scale multiplies, it also becomes clear where raising it stops doing anything.

Output size is canvas size times scale

The scale multiplies the size of the working canvas, and the canvas size depends on the format you picked.

That table lists all 18 formats, with none left out. Since the subject of this article is what the scale multiplies, the full list earns its space here rather than a few representative examples. Whichever format you picked, it is on one of those four rows.

Those 18 are every format in the list, and none of them uses a portrait canvas.

Exporting Single at 2x gives 2160 × 2160. The output size shown in the export panel is that calculation.

Your upload has already been shrunk

This is the part that matters. An uploaded screenshot with a long edge over 2000 pixels is scaled down to 2000 pixels before you work with it. That keeps memory use in check during editing, and the aspect ratio is preserved.

So uploading a 6000 pixel screenshot and exporting at 4x does not bring the original detail back. What gets enlarged is the 2000 pixel bitmap. On top of that, the bitmap does not fill the canvas. It sits inside the screen area of the device. In the Single format the screen area is smaller than the canvas, so the pixels actually spent on your screenshot are far fewer than the output size suggests.

The same 2000 pixel cap applies to a background image. A background covers the entire canvas rather than a screen area, so the loss from enlargement is greater. Export a 1920 × 1080 canvas at 2x and a 2000 pixel original has to fill 3840 pixels of width.

The practical conclusion: 2x covers most uses, and 3x or higher earns its place only when the image will be enlarged, as in print (inference, the right scale for a given use is not something the code decides).

Sometimes a scale is locked

Apple's browsers cap canvas area. When the output area passes that cap, the result is a blank image. Scale buttons that would cross the cap are locked before you press them.

That lock exists because the compositing and the export both finish inside the browser rather than on a server. Your upload is never sent anywhere, and in return the canvas that builds the result has to stay under the ceiling the browser sets.

The table below applies that area limit to sizes worked out from the code values.

The check marks and crosses come from substituting the area limit of 16,777,216 described in the external fact section below.

The lock is decided from the browser user agent string. It covers every browser on iPhone and iPad, and Safari on any platform. Chrome, Edge, and Firefox on macOS, and Chromium browsers on Windows and Android, are not covered, so all four scales stay open there. The test is not Apple hardware. It is an iOS device or Safari according to the user agent.

If the image conversion step returns an empty result, it retries once. If the retry is also empty, you are told to lower the scale. Other failures, such as a browser that cannot composite the canvas at all, are reported separately and are not retried.

Transparency and file formats

A transparent background works with PNG and WebP only. JPG cannot carry transparency at all, so the chosen background color is laid down first and the composite goes on top of it. Turning transparency off and exporting PNG fills the background the same way.

The export hides the editing tool layers. Selection handles and alignment guides never reach the result.

In short

• Output size is the canvas size of the format times the scale, and the scale runs from 1x to 4x.
• Uploads are scaled to a 2000 pixel long edge, so raising the scale does not recover detail from the original.
• On Apple's browsers a high scale can be locked by the canvas area cap. Edge length is not part of the test.
• Pick PNG or WebP when you need a transparent background.

External fact: browser canvas limits

What the sources confirm

WebKit caps area only. There is no cap on width or height. The source comment says so.

Firefox limits width/height to 32767 pixels... We limit by area instead, giving us larger maximum dimensions, in exchange for a smaller maximum canvas size.Source W1

The iOS area cap has changed once since it was introduced.

• Other platforms, meaning desktop, sit at 16384 × 16384 = 268,435,456 (W1)
• Apple's developer documentation does not carry these numbers. They appear never to have been documented officially, and the only evidence is the WebKit source and the bug tracker.

Where our implementation differs, stated plainly

This service checks area only, the same way WebKit does, as of 2026-08-22. Edge length is not part of the test.

The value we apply is still the 2015 one, 16,777,216. The cap rose to 67,108,864 in March 2024, but the lower number is kept as a safe floor so that older iOS, meaning 17 and below, does not hand back a blank image. On a recent iPhone that makes us more conservative than the browser actually is. Raising it means first deciding the oldest OS we support.