The Real Limits of a Browser-Based Image and Video Tool

Every tool has a ceiling. Most of them will not tell you where it is until you hit it, and browser tools are worse than most, because the failure is often not an error message but a tab that goes white and reloads itself.

So here are the actual numbers, and more usefully, the reason behind each one. Knowing why a limit exists tells you whether you can work around it or whether you are on the wrong platform for the job.

Why a tab has a budget at all

A browser tab is a sandbox with a memory allowance. That allowance is not generous, it is not the same on every device, and when a tab exceeds it the browser does not politely decline. It kills the tab.

Everything below exists to keep work inside that allowance. The alternative is not "the same work but slower". It is losing what you were doing.

There is also a second constraint that is easy to forget. An image on disk is compressed. An image being worked on is not. A 12-megapixel photograph is perhaps 4 MB as a JPEG and about 48 MB as raw pixels, and a pipeline holds several copies at once: the decoded source, a working copy, a model's input, the result. Multiply by a batch and the arithmetic gets uncomfortable quickly.

The image dimension ceiling, and why it moves

Images are capped when they are decoded, at 4096 pixels on the long side on a desktop machine. On a phone the cap is 1536, and on a device that reports itself as low on memory it is 1024.

The cap being device-aware is the important part. A full-resolution phone photograph opened on the phone that took it is the single most reliable way to kill a mobile tab, so the downscale happens before anything else runs rather than after the pipeline has already allocated several copies.

At 4096 pixels, an image is about 13.6 inches wide at 300 dots per inch, which covers a great deal of print work and does not cover a poster. If you tell the tool you gave it something larger, it tells you it scaled it down. It does not pretend otherwise.

There is a floor as well: below 64 pixels on a side you get a warning, because a model given a 40-pixel image is being asked to find edges that are not there.

File size and duration

An image may be up to 100 MB. A video may be up to 500 MB and up to 5 minutes long.

The video numbers are the ones people meet. Five minutes is not a long film, and that is deliberate: decoding video frames into memory is expensive, and a browser tab is not where a 40-minute recording should be processed. If your source is longer, trim it first, or work in sections.

Separately, transcription is limited to 15 minutes of audio per run, and burning captions into a clip is limited to 60 seconds of opaque output or 30 seconds when transparency is being preserved. Those are tighter than the general video limits because they are different operations with different appetites: transcription decodes the entire audio stream to samples, and caption burn-in renders every frame.

A memory check runs before several of these and can ask for something shorter or lower-resolution on a given device before it starts. A refusal leaves your source untouched, which is the behaviour you want: being told no is better than being told yes and losing the tab at 80 percent.

Batches

The batch queue holds up to 100 images. When it is full and you add more, finished items are evicted and their decoded bitmaps released to make room, so a long run does not accumulate every result it has ever produced.

In practice the limit you meet first is rarely the count. It is the size. One hundred small product shots is comfortable. One hundred full-resolution camera files is a different proposition, and the honest advice is to resize them to the dimensions you actually need before the batch rather than after, which makes every step lighter and costs nothing you were going to keep.

Undo history, and the number that looks wrong

The editor keeps up to 50 undo steps. For destructive operations that replace the whole image, it keeps 8.

That second number looks stingy until you see what is behind it. A mask adjustment or a colour grade is a small piece of state. A destructive step holds full-resolution image data for before and after, so each one is worth many megabytes at working resolution. Keeping 50 of those would mean an editor that works beautifully for ten minutes and then dies.

So the two histories are capped separately, the heavy entries are dropped oldest-first, and the light ones keep their full depth. It is an honest trade rather than an oversight.

Stored data

Roughly 1 GB of browser storage is used for cached models and working data.

Models download once, after you approve that specific version, and the browser caches them. That is what makes a second run instant and what makes these tools work with no connection afterwards.

The caveat worth knowing: browser storage is not permanent. Clearing site data removes it, private browsing windows start empty, and browsers can evict caches under storage pressure. A model that downloaded last week may download again. It is not lost work, just a wait you did not expect.

The limits that are not numbers

Some ceilings are not quantities.

Browser codec support decides whether a video's audio track can be decoded at all. A file using an unusual codec may open with a picture and no readable sound, and no setting on this end changes that.

An MP4 cannot carry transparency, so operations that would need an alpha channel in an MP4 do something else instead, such as filling a transparent pad with black. That is the format, not the tool.

And model quality is a limit like any other. A background removal model has failure cases, a transcription model mishears names, and a deblur model cannot recover detail that the sensor never recorded. The tools that are honest about this are more useful than the ones that are not.

Working inside them

When you hit a ceiling, the workarounds are dull and effective.

Resize and trim before you process, not after. Split a long video into sections. Close the twenty other tabs, because they share the same machine. Use a desktop machine for anything large, since the caps on phones are lower for a real reason. And do the cheap operations first so the expensive ones have less to carry.

What this is honestly not for

These limits describe a real boundary and it is better to say where it is than to let you find it at the wrong moment.

A feature-length edit, a 100-megapixel print file, a thousand-image overnight batch, or a multi-hour transcription are jobs for desktop software with the whole machine at its disposal. That is not a failing to apologise for; it is a different tool for a different job.

What a browser tab is genuinely good at is the enormous middle of the work: a listing photo, a headshot, a short clip, a batch of product shots, a caption pass on a tutorial. For all of that the ceiling is a long way above what you need, and the thing you get in exchange is that the file never leaves your machine.

Every cloud tool has these same limits. They are simply someone else's limits, on someone else's hardware, and the price of not having to think about them is that your image is on that hardware.