Why metadata removal fails on very large photos

This is a different problem from a file a tool simply will not accept. An unsupported format is an honest, immediate refusal: you hand over a HEIC, a RAW file or a PDF, the type check rejects it on sight, and the message names the reason. An oversized JPEG is the opposite experience. It is a supported format. It passes the type check. The metadata scan runs and reports findings. The preview appears. Everything about the first two steps says this is working — and then the one step that actually produces the clean file falls over, with an explanation that points at the wrong thing. Understanding why turns an unexplained dead end into a two-minute diagnosis.

Megapixels, not megabytes

A JPEG on disk is compressed. The number your file manager shows you is the size of the compressed bytes, and compression ratios for photographic content vary by an order of magnitude depending on the subject, the quality setting and the camera. That number tells you almost nothing about the cost of working with the image, because nothing can edit a compressed JPEG's pixels directly. The picture has to be decoded first, and a decoded image is not compressed at all.

The arithmetic is simple and it is worth doing by hand once. The pixel representation the canvas APIs expose is four bytes per pixel: the HTML specification sets bytes-per-pixel to 4 for the default rgba-unorm8 format, allocates a buffer of four times rows times pixels-per-row, and stores each pixel as four sequential values in the order red, green, blue, then alpha. So the rough decoded footprint of any image is width × height × 4. Run that over some real shapes:

• A standard 12-megapixel phone photo, 4032 × 3024 — about 12.2 million pixels, so roughly 49 million bytes of raw pixel data. The file on disk might be 3 MB.
• An A4 page scanned at 600 dpi, 4960 × 7016 — about 34.8 million pixels, roughly 139 million bytes decoded.
• A 48-megapixel capture, 8064 × 6048 — roughly 195 million bytes decoded.
• A stitched panorama at 20000 × 4000 — 80 million pixels, roughly 320 million bytes decoded, from a file that may well be under 10 MB because so much of a sky compresses to nearly nothing.

That last line is the whole point. The panorama is the smallest file in the list and by far the largest image in it. Two photos with identical file sizes can sit on opposite sides of the ceiling, and two photos where one is ten times the other on disk can land in the reverse order once decoded. If you are trying to work out whether a photo is "too big", the file size is not a weak signal — it is the wrong measurement.

The three separate things that can fail

A canvas-based strip is three operations in sequence, and each has its own limit. They fail for different reasons and they fail at different sizes, which is part of why the behaviour feels arbitrary.

1. The decode. Before anything can be redrawn, the compressed file has to be turned into a bitmap in memory. The HTML specification is explicit that this step rejects with an InvalidStateError when the source image data cannot be decoded. On a large file that can mean genuine corruption, but it can equally mean the decoder declined to allocate what the image needed.

2. The canvas. The decoded bitmap then has to be drawn onto a canvas at the image's own dimensions, and this is the hard, published ceiling. MDN states that the exact maximum size of a canvas element depends on the browser and the environment, that in most cases the maximum dimensions exceed 10,000 × 10,000 pixels, and that iOS devices notably limit the canvas to only 4,096 × 4,096. It adds a blunt note: exceeding the maximum dimensions or area renders the canvas unusable, and drawing commands will not work. Note what 4,096 × 4,096 amounts to — under 17 megapixels. A 12-megapixel phone photo fits. A 600 dpi A4 scan, a high-resolution camera mode and any panorama do not, and that limit is attached to the device you are holding rather than to the photo.

3. The export. Finally the canvas has to be serialised into a new JPEG or PNG. The function that does this is documented to pass null to its callback if the image cannot be created for any reason — a deliberately broad phrase that covers both an unusable canvas and an export the browser could not complete. There is no error code and no diagnosis; the result is simply absent.

Alongside all three sits ordinary memory pressure, which is less crisp and varies too much to state precisely. A tab has a finite share of the device's memory, and the decoded bitmap, the canvas backing store and the encoder's working buffers can all be alive at once. Whether that becomes a failed step, a long freeze or a reloaded tab depends on the device, the browser, what else is open and how much physical memory is free, so it is worth knowing about and not worth predicting.

What the failure actually looks like in this tool

Because this page is about diagnosing a dead end, here is exactly what the code on this site does, read from the script rather than assumed.

There is no size guard at all. The only check applied to an incoming file is the type test: the allowed types are image/jpeg and image/png, with a filename-extension fallback, and that is the entire gate. No byte-size threshold, no dimension threshold, no warning. The canvas is then set to the bitmap's own width and height with no cap and no automatic downscale, which is the correct choice for fidelity — your clean copy comes out at full resolution, not quietly shrunk — and it is also the reason an oversized image runs straight into the browser's ceiling instead of being resized behind your back.

The scan will always succeed, which is misleading. The metadata check reads only the opening slice of the file — the first 512 KB at most, and it examines a smaller window than that within a JPEG. Headers live at the front of a file, so that slice is all it needs, and it costs nothing regardless of whether the file is 200 KB or 200 MB. A 300-megapixel scan will therefore report "Possible EXIF metadata found" instantly and confidently. That reading is correct. It is also no evidence whatsoever that the removal step will work, because the two operations have nothing in common: one reads a few hundred kilobytes from the front, the other decodes every pixel.

The preview proves nothing either. The original is previewed by pointing an image element at an object URL, which is the browser's ordinary image display path. The canvas is a separate path with separate limits, and the display path is generally the more forgiving of the two. Seeing your photo appear on screen tells you the browser can show it. It does not tell you the browser can rebuild it.

All three failure points produce one identical sentence. Decode, canvas and export are wrapped in a single try block, so whichever one fails you get: "Could not process this image. Try a different JPEG or PNG file." For a corrupt file that is reasonable advice. For a 90-megapixel panorama it sends you looking for a problem with your format that does not exist. If you have read this far, treat that message on a known-good large photo as meaning "too big for this browser on this device", not "wrong kind of file".

Nothing is half-done. The clean copy is produced in one shot and only then offered to you, so a failure leaves no output file, and the download button never appears. The original is never touched — the tool writes a separate file with -metadatawipe appended to the name. The process button is re-enabled so you can try again, but retrying the identical file in the identical browser will fail identically; the thing to change is the file or the browser, not the number of attempts.

A workflow for a photo that will not go through

1. Find the pixel dimensions. Not the megabytes. File properties on Windows, Get Info or the inspector on macOS, or the info panel in your phone's photo app will all show width × height. Multiply them. Anything above roughly 17 megapixels is in the risky band on a mobile device; anything above 100 megapixels is in the risky band almost everywhere.
2. Try a desktop browser. If the failure happened on a phone or tablet, this one step resolves a large share of cases on its own, because the published mobile ceiling is dramatically lower than the desktop one. Move the file to a computer and run it there.
3. Try a second browser on the same machine. The limits belong to the rendering engine, not to the operating system, so two browsers on one computer can genuinely disagree about the same file. This costs a minute and occasionally just works.
4. Ask whether you need full resolution. Most destinations downscale aggressively anyway. If the image is going into a message, a listing, a forum post or a web page, exporting it at a sane size first is not a compromise — it is what was going to happen to it regardless, and you get to control the quality of the resize rather than leaving it to someone else's server.
5. If you resize, resize first and strip last. A resize is an edit, and the app performing it writes the output file, so it decides what goes into the new header. Make the removal the final operation so that nothing writes to the file after it. The general principle, and the traps in the other order, are covered in in what order should you crop, edit and strip metadata from a photo.
6. If full resolution is non-negotiable, change tools rather than tactics. Desktop metadata utilities that rewrite the header in place never decode the pixels at all — they locate the metadata segments and remove them, leaving the compressed image data untouched. That makes the pixel count irrelevant to them, and it has a second benefit: no re-encode, so no generational quality loss on a photo you presumably care about. This is the structural reason such tools handle gigapixel images that no browser page can.
7. Verify whatever you end up with. Whichever route worked, check the file you are actually going to send rather than assuming the step succeeded, and check the copy rather than the original.

Why a browser tool has a ceiling in the first place

It is tempting to read a size limit as sloppiness. It is closer to the opposite. The limit exists precisely because the work is happening on your device, inside one tab, using that machine's memory and that engine's published maximums. Those constraints are the shape of local processing. A service that cheerfully accepts a 400-megapixel scan without blinking is not using a better canvas — it is doing the work on hardware it controls, with as much memory as it cares to allocate, which means the bytes went there to be worked on.

So the failure you just hit is, awkwardly, evidence of the property the site claims. It is also a reason to be suspicious of the opposite experience: if a page handles anything you throw at it instantly, that tells you something about where the decoding happened. The broader question of how to check a browser tool's claims for yourself — what to look at, what proves what, and which observations are worthless — is covered in how to tell if a browser tool really processes your photo locally.

Common mistakes and misconceptions

"It said wrong file type, so my JPEG must be corrupt." The message is a single catch-all covering three unrelated failure modes, and it was written with corruption in mind. If the file opens fine in your photo viewer, your editor and the preview on this very page, corruption is the least likely explanation left.

"It is only 9 MB, it cannot be too big." The most common misdiagnosis on this page, and the reason panoramas are the classic failing case. Megabytes measure compression; the ceiling measures pixels. They are not the same quantity and they are not even reliably correlated.

"The preview loaded, so the file is fine." Display and canvas rebuild are different code paths with different limits. The preview is a reassuring picture, not a test result.

"Maybe it stripped some of it before it failed." No. There is no partial output; a clean copy either exists in full or does not exist. If no download appeared, nothing was produced, and the file still sitting on your disk is your untouched original with every tag still in it.

"It worked on my laptop, so it will work on my phone." This is the one failure in the metadata world that runs the opposite way from most. Phones and tablets have the lowest documented canvas ceilings, so the device most likely to be holding the photo is the device least likely to be able to rebuild it.

"Closing other tabs will fix it." It can help if what you ran into was memory pressure, and it cannot help at all if what you ran into was a hard dimension limit, because that number does not move with available memory. Worth one try, not worth ten.

"A bigger file must have more metadata in it." There is no relationship. A header holding GPS coordinates, a full camera and lens record, timestamps, author strings and an embedded preview thumbnail is typically a few tens of kilobytes whether it is attached to a 500 KB web graphic or a 180 MB scan. Large files are not more exposed; they are just harder to process.

"A tool that fails on big photos is a worse tool." For this specific job it is a less capable one, and you should go and use something else for that file. But the failure is a property of doing the work in a tab on your own hardware, and the alternative that never fails is the alternative that moved the work elsewhere. Pick deliberately rather than by which page threw an error.

Related guides

See also:

• In what order should you crop, edit and strip metadata from a photo?
• How to tell if a browser tool really processes your photo locally