I wanted to know where a browser-based image editor actually falls over, so I built the worst project I reasonably could: 24 pages, one of them stacked to 24 layers, canvases pushed toward the 8192px ceiling. The hard limits are stated up front — up to 8192px per side, around 48 million pixels, 24 layers per canvas, 24 pages per project — and I wanted to feel what living at those limits is like, not just read the numbers off a spec.
Online Design (imging.ai) runs entirely client-side; nothing you import is uploaded. That is reassuring for privacy, but it also means the tab's memory is the entire budget. A single 8192×5900 layer is roughly 48 megapixels, and at 4 bytes per pixel that is about 190 MB uncompressed — per layer. Twenty-four of those held simultaneously at full resolution would be several gigabytes, which no tab will tolerate. So the real question is not whether the tool is fast, it is how it avoids ever doing that.
The answer is that it never holds everything at full resolution while you work. The editing preview is rendered at a resolution matched to your viewport, not the canvas. Dragging layers, reordering them, tweaking opacity on the busy 24-layer page all stayed responsive because I was manipulating a downscaled composite, not four-and-a-half gigabytes of pixels. Full resolution is only assembled at export time, and even then not all at once.
Export is where a naive implementation would crash. Instead of allocating the entire full-resolution canvas plus every filtered intermediate, high-resolution work is done in horizontal strips: a band is composed and filtered, written out, and its memory released before the next band begins. Exporting the maxed-out page took time and the fan spun up, but the tab held steady. Peak memory tracks the size of a strip, not the size of the whole canvas — that is the entire trick, and everything else follows from it.
Rough behaviour from the run:
| Scenario | Behaviour |
|---|---|
| 24 pages, light layers | Smooth, near-instant page switching |
| Single 24-layer page, editing | Responsive; preview stays fluid |
| 8192px export, filtered | Slow but completes, tab stable |
| Two maxed pages open at once | Noticeable lag, no crash |
If you want to push it yourself, the flow is straightforward. Create a canvas at a large custom size, import images and stack layers up toward the 24 limit, add more pages up to 24, apply a filter to the whole canvas, then export — try both single-page PNG and the per-page ZIP. Watch the browser's task manager while the export runs and you will see memory climb during a strip and settle again between strips, rather than growing without bound until the tab dies.
The three export routes behave differently under load, which is worth knowing before a big job. Exporting the current page is the lightest. The per-page ZIP walks all pages sequentially, so it stays flat in memory even across a 24-page project. The high-resolution multi-page HTML bundle is the heaviest but keeps everything in one file. For the maxed project the ZIP was the route I trusted most not to spike.
The honest verdict: a browser tab will not match a desktop app with disk-backed scratch space, and you can feel that at the ceiling, where the maxed export is not instant. But it did not break, and the reason is architectural rather than luck. Adaptive preview keeps editing cheap, strip processing keeps export bounded, and per-page limits keep any single canvas inside what a tab can actually hold. The limits are not arbitrary — they are the numbers that stop it from becoming the thing that crashes.
Top comments (0)