2026-09-08

Why an upload rejects your image — and which of the four limits you actually hit

The upload fails. The message says something vague about size. The reflex is always the same: run the photo through a compressor, drag the quality slider down, try again. Sometimes that works. Just as often it changes nothing at all — because the thing that rejected your image was never counting bytes in the first place.

"Too large" is at least four different failures wearing the same coat. Each one has a different fix, and picking the wrong fix is why people end up with a mushy 40 KB photo that the site still won't take. Here is how to tell them apart in about ten seconds.

Four ceilings, four fixes

1. The byte ceiling — the only one compression solves

This is the familiar one, and the numbers span orders of magnitude depending on where the file is going. GitHub's own docs put the ceiling for attachments at "10MB for images and gifs". Korea's national qualification-exam portal, Q-Net, runs by far the tighter rule: its official photo-registration guide states the registrable file must be *.JPG or *.JPEG and 200 KB or under — fifty times stricter than GitHub, on a photo you cannot skip if you want to sit the exam.

A byte ceiling is the one case where dragging a quality slider is exactly the right move: JPEG and WebP re-encode with less precision, the pixel dimensions stay identical, and the file gets smaller. (An earlier post on this blog covers why the slider percentage itself never predicts the resulting size, and why watching a live estimate beats download-and-check.)

2. The pixel ceiling — where compression is powerless

A pixel cap counts width × height. Nothing you do to the encoder changes it. Compress a 6000 × 4000 photo from 12 MB down to 400 KB and it is still 6000 × 4000, still 24 megapixels, and still 6000 px along its longest side. If the form wanted nothing wider than 5000 px, you have not moved a millimetre toward passing it.

Shopify states both ceilings in one breath, which is a good illustration of how easy they are to conflate. Its product media documentation says images "can be any size up to 5000 x 5000 px, or 25 megapixels," and separately that they "need to have a file size smaller than 20 MB to be added to Shopify." Two independent tests. A perfectly small 300 KB panorama at 9000 × 2500 sails through the second and fails the first.

The clearest demonstration that these are unrelated comes from MediaWiki, the software behind Wikipedia and Wikimedia Commons. Its manual for $wgMaxImageArea documents a default of 12,500,000 pixels — about 3500 × 3500 — described as "Don't thumbnail an image if it will use too much working memory," and notes that "users are still allowed to upload large files." Go over it and the upload succeeds; what you get instead is Error creating thumbnail: File with dimensions greater than 12.5MP. The bytes were never the issue. The decoded image was.

That last phrase is the whole mechanism. Decoding an image costs roughly width × height × 4 bytes of memory regardless of how small the compressed file is, so any service that has to open your picture — to make a thumbnail, to scan it, to re-encode it — has a pixel-count budget entirely separate from its upload budget. Google Photos applies the same logic at the storage end: its backup-quality help page says that in Storage saver, "If a photo is larger than 16 MP, it'll be resized to 16 MP."

The arithmetic is easy and worth doing once: megapixels are just width × height divided by a million. 6000 × 4000 is 24 MP. 4032 × 3024 — a very common phone frame — is about 12.2 MP, comfortably under most caps. A stitched panorama or a flatbed scan is where people quietly cross the line without a large file to warn them.

3. The format ceiling — your phone's fault, mostly

The third failure produces the least helpful error of all, usually a bare "unsupported file type." GitHub's supported-types list, on the same docs page as the 10 MB cap, names exactly four image formats: PNG, GIF, JPEG and SVG. No WebP. No HEIC. Q-Net accepts JPG and JPEG and nothing else. The photo you are trying to upload is, if you own a recent iPhone, quite possibly none of them.

Apple's own support note, Using HEIF or HEVC media on Apple devices, explains the setting behind this: choosing Settings → Camera → Formats → Most Compatible means "all new photos and videos will then use JPEG or H.264 format instead of the space-saving HEIF and HEVC formats." The same page notes that when you import HEIF media from an attached iPhone into Photos, Image Capture, or a PC, "the media might be converted to JPEG or H.264" — which is precisely why the problem is invisible until the one time you upload straight from the phone and the conversion never happens.

The fix is a format conversion, not a compression. Note that this ceiling can stack with the others: Q-Net wants JPG and 200 KB, so a HEIC selfie needs both operations before it will be accepted.

4. The format's own hard ceiling — the one nobody mentions

Even with no site policy involved at all, each image format has a maximum size baked into its file structure, because the header field that stores the dimensions is only so many bits wide. These are not opinions or recommendations; they are what the bytes can physically express.

WebP is the one that bites in practice, and 16,383 is not a large number if you scan artwork or stitch panoramas. A 20,000-pixel-wide image cannot be a WebP at all, no matter how it is encoded or how small the result would be — the format has nowhere to write the width. Any tool that appears to do it has resized on your behalf.

There is a fifth ceiling underneath all of this if the tool runs in a browser, ours included. MDN's reference for the canvas element puts it plainly: "the exact maximum size of a canvas element depends on the browser and environment. While in most cases the maximum dimensions exceed 10,000 x 10,000 pixels, notably iOS devices limit the canvas size to only 4,096 x 4,096 pixels," and "exceeding the maximum dimensions or area renders the canvas unusable." Every browser-based image editor is standing on that floor.

Find your actual numbers first

Before changing anything, look at what you have. On Windows, right-click the file → Properties → Details shows dimensions and size; on macOS, select it and press Cmd + I, or open it in Preview and use Tools → Adjust Size. On a phone, the photo's info panel gives the same two numbers. Then read the destination's stated limits — they are usually one line of small print next to the upload button — and check them separately: bytes against bytes, pixels against pixels, extension against the accepted list.

Dropping a file into NearIMG does the reading part for you: every file on the workspace shows its real dimensions and file size as W×H · size, read from the file's own bytes rather than its name, and the compress and resize panels show a measured estimate of the output size that updates as you change settings.

Doing all four in one pass, on your own device

NearIMG is a set of browser-side image tools; nothing you drop in is uploaded anywhere, which is the point of it. Mapped to the four ceilings above: the compress tool moves bytes, resize moves pixels (either to a pixel box that keeps the aspect ratio, or by percentage), and convert writes JPG, PNG or WebP. You can apply all three settings at once, and if you drop in a folder of photos the same settings are applied to every one of them and the result comes back as a single ZIP — which is the usual shape of the problem when a form wants twenty photos that all obey the same rule.

What NearIMG can and cannot do here

Since this article is about limits, ours belong in it:

• Input size. 100 MB per file and 400 MB per batch on a desktop browser; 30 MB and 100 MB on a phone, or on any device that reports 4 GB of memory or less. Anything over that is rejected before it is opened.
• A pixel ceiling of our own. Images above roughly 120 megapixels are refused (40 MP on those same low-memory devices), for exactly the reason described above: a decode allocates width × height × 4 bytes and a tiny file can claim enormous dimensions. For PNG and SVG the declared size is read from the header before any decode happens.
• The browser's canvas ceiling still applies. A file that clears our guard can still be too big for the canvas the browser gives us, particularly on iOS, and there is nothing we can do about that from inside the page.
• Output formats are JPG, PNG and WebP only. No AVIF, no TIFF, no PSD, no SVG output. GIF, BMP, HEIC and SVG inputs come out as PNG unless you pick one of the three.
• HEIC input works, at a cost. Most browsers cannot decode HEIC, so we load a WebAssembly build of libheif (about 1.4 MB) from our own site, and only when you actually drop a HEIC file. AVIF input depends on whether your browser can decode AVIF itself.
• We do not check the output format's hard ceiling for you. Ask for WebP from something wider than 16,383 px and the browser's encoder decides what happens, not us. Resize first.
• The GIF maker is deliberately small. Output width is one of 240, 360 or 480 px and the height is capped at 1000 px, because an animated GIF at photo resolution is enormous.
• Metadata does not survive. Every output is a freshly encoded file with no EXIF, no XMP, no colour-profile block. Useful when you want the GPS coordinates gone; a problem if you needed the original's provenance, in which case keep the original untouched.

The short version

"Image too large" is four unrelated failures sharing one error message. Bytes are fixed by compressing — GitHub caps images at 10 MB, Q-Net at 200 KB. Pixels are fixed by resizing and are completely unaffected by compression — Shopify's separate 5000 px / 25 MP and 20 MB limits and MediaWiki's 12.5 MP thumbnail ceiling (where the upload succeeds and the thumbnail fails) are the proof. Formats are fixed by converting — GitHub lists PNG, GIF, JPEG and SVG and nothing else, and your iPhone is probably shooting HEIC. And every format has a physical ceiling in its own header: 16,383 px a side for WebP, 65,535 for JPEG and GIF. Check the two numbers your file actually has before you touch the quality slider, and you will pick the right fix the first time.