"The file you are trying to upload is too large": 84 KB is not the number the form checked
Every form that produces this sentence is saying one number is over one limit, and none of them says which number. There are two candidates: the bytes on disk and the pixels the file decodes into. An 84,394-byte PNG measuring 4000 × 4000 is 16.00 megapixels, which makes it the file that settles the question — small enough that a 300 KB byte target hands it back untouched, large enough to fail a 12-megapixel ceiling.
The unit printed in the message is the whole diagnosis. MB or KB means bytes. Pixels, px, MP or dimensions means area. One of those two decides whether the fix is a re-encode or a resize, and applying the wrong one costs pixels that nobody asked you to give up.
Read the unit before you change the file
- "Too large" is identical everywhere; the unit after it is not. The same three words arrive as "maximum 2 MB", as "max 4096 px", as "at least 1080 px wide", and as "too large for the server" with no unit at all. Only the first is fixed by compressing. The second and third are fixed by removing pixels, and no amount of compression moves them.
- If there is no unit, the form's own published limit is the only other evidence. Three platforms publish one that can be checked against their own documentation, and they are in the table below. The rest either publish nothing or could not be retrieved — that is stated as it is, not filled in with a number that sounds right.
Every measured figure on this page was produced on 28 October 2026 by this site's own compressor running on real files on this machine. Where a number is arithmetic rather than a measurement, the sentence says so.
Test conditions: Chrome 155 on Windows 11, this site's compressor served locally on
127.0.0.1, one file at a time through the normal file input. Byte counts come from fs.statSync
on the file on disk, and for outputs from the page's own report object. Pixel dimensions are the decoded
ImageBitmap.width and ImageBitmap.height after createImageBitmap() on
the same File object the tool decodes — the numbers the browser actually loaded, not the ones in the
filename. Every figure was taken twice on the same day, from the same fixture files, and the two runs
agreed byte for byte.
The unit, not the adjective
Four forms, four ways of saying the same thing, and they do not mean the same thing:
| What the message says | What it is counting | What actually fixes it |
|---|---|---|
| "Maximum file size 2 MB" | Bytes on disk | A re-encode at a lower byte target |
| "Max 4096 px", "max 12 MP", "dimensions too large" | Width × height | Fewer pixels — a resize |
| "Images must be at least 1080 px wide" | Width only | Enlarging, which is the opposite direction |
| "The file you are trying to upload is too large" | Unstated | Nothing, until you find which of the two the form compares |
Four wordings, no measurement involved — this is a reading of what each sentence names. The last row is the one this page is about, and it is the only one that cannot be answered from the message alone.
The reason the distinction matters is that the two numbers are independent measurements of the same file. Bytes describe how much detail the encoder had to store. Pixels describe how much work the decoder has to do. A flat graphic can carry sixteen million pixels in eighty-two kilobytes, and a photograph of the same pixel count can need three megabytes to describe the same area. Whichever number the form compares is the one you have to lower, and lowering the other one changes nothing it looks at.
That is the trap this message sets. Compressing is the first thing to try, because it is the only lever most tools offer — and it is the right lever for one of the two readings. For the other reading it looks like it works, while it throws pixels away at a rate you did not choose and cannot see from the target number you typed. The measurement in the third section is what that costs.
Three published limits, and what each one counts
These are the only limits on this page taken from a company's own documentation, read on the date shown. The middle column is quoted, not paraphrased, because the wording is the evidence: one of these three states both numbers in a single sentence, one states only pixels, one states only bytes.
| Where | What the page says | Which number it counts | Source |
|---|---|---|---|
| Gmail attachments | "For personal Gmail accounts, the limit is 25 MB." | Bytes only | support.google.com/mail/answer/6584, section "Learn how attachments work in Gmail", read 28 October 2026 |
| Shopify product images | "any size up to 5000 x 5000 px, or 25 megapixels" … "a file size smaller than 20 MB" | Both, in one sentence | help.shopify.com/en/manual/products/product-media/product-media-types, read 28 October 2026 |
| Instagram photos | "up to a width of 1080 pixels" … "we size it down to a width of 1080 pixels" | Pixels; the page states no byte limit, and it describes no rejection — Instagram shrinks the width to 1080 px itself | help.instagram.com/1631821640426723, read 28 October 2026 |
Three rows, 28 October 2026. The Gmail row is the case where compressing is the right answer. The Instagram row is not a rejection at all: that page describes no limit it refuses and no error it returns — it takes the upload and sizes the width down to 1080 pixels itself, so the "too large" message a reader meets in a form comes from the form, not from Instagram. The Shopify row is the case that makes the message ambiguous even when the platform is being helpful: both numbers are published, and the error you get back still does not say which one you crossed.
Four other places this message comes from publish no number I could verify — X keeps its size requirements
in a collapsed help entry that would not open, Discord's own documentation gave me no figure at all
(secondary sources disagree at 25 MB, 10 MB and 20 MB, which is exactly why none is printed here), Stack
Exchange's /help/image-uploads returns 404, and the Moodle thread that ranks for this phrase
sits behind a captcha — so the table has three rows instead of seven with four invented.
A number without a source is worse than a blank. If you are looking for the limit of a specific site and it is not in the table above, the site's own help pages are the only place that can answer it. Anything else you read is someone's recollection of what the limit used to be, and these limits change.
84 KB, two byte targets, and the pixels that did not move
One file, measured twice on 28 October 2026: a flat graphic, 84,394 bytes on disk (the interface prints 82 KB), 4000 × 4000 pixels, which is 16.00 megapixels (arithmetic: 4000 × 4000 ÷ 1,000,000).
At a 300 KB target it came back at 84,394 bytes, still 4000 × 4000, in a reported 0 ms. Nothing was re-encoded, because the file was already inside the limit and already in the requested format, so the tool handed the original back. That result is the answer to every byte-based version of this error: the file already passes, and compressing it again cannot help.
At a 50 KB target the same file came back at 50,679 bytes, 1016 × 1016, in a reported 1,134 ms. That is 1,032,256 pixels, or 1.03 megapixels — 6.4516% of the pixels it started with, a loss of 93.55% (both arithmetic: 1,032,256 ÷ 16,000,000).
The two runs answer the two readings of the same error. If the form said MB, the first run is your whole answer: the file was already under the limit and the message was about something else. If the form said megapixels, the second run shows what happens when a byte target is used to fix a pixel problem — it does get under a 12-megapixel ceiling, at 1.03 MP, when 12.00 MP would also have passed.
Which is why the order of operations matters more than the tool. Read the unit, decide which number is being compared, and only then pick a lever: a byte target when the message counts bytes, a resize when it counts pixels. The compressor on the front page prints both numbers — bytes and pixels — as soon as a file is loaded, before you choose a target, so the number named in the error can be matched to the number it refers to.
Questions this page gets
The file is only 84 KB. Why would a form call that too large?
Because it may be counting pixels. 84,394 bytes at 4000 × 4000 is 16.00 MP, and a form with a 12 MP ceiling rejects it while accepting a 3.49 MB photograph that is 24.00 MP but weighs forty times more on disk. The small file loses on the number the form is actually comparing. Nothing about the file changed between the two rejections except which number the receiving side looked at.
The message says only "too large", with no unit. What now?
Find the form's own published limit before touching the file. If it publishes nothing, take the cheap branch first: a byte target, because it is fast and reversible. If the file was already small and the form still refuses it, stop compressing — the form is counting pixels, and no byte target moves that number.
Does compressing to 50 KB get a 16-megapixel image under a 12-megapixel limit?
It does: 1016 × 1016 = 1.03 MP, measured. But you did not need to go that far. A trim to 3464 × 3464 is 12.00 MP and would also have passed — the edge factor is √(12 ÷ 16) = 0.8660, a 13.4% cut on each side. The byte target and the pixel ceiling are two different dials, and turning the wrong one hard enough to work costs the picture.
Can I rely on the 25 MB figure people quote for Discord?
Not from this page. I could not get a file size limit out of Discord's own documentation, and secondary sources give 25 MB, 10 MB and 20 MB. One of those may be current; I cannot tell which, so the table above stops at the three limits I could read on the company's own site.
Which of the published limits counts pixels rather than bytes?
Instagram's page states a width of 1080 pixels and no byte limit at all. Shopify states both numbers in one sentence — 20 MB and 5000 × 5000 pixels, or 25 megapixels. Gmail states only 25 MB for personal accounts. Three platforms, three different ways of describing the same kind of ceiling.
If the number in your error is bytes and you have already checked the unit, the measured pixel budget for each byte target is on 300 KB (4.84 MP), 500 KB (8.41 MP) and 1 MB (19.75 MP kept whole).
If you do not yet know which kind of limit you are hitting, the triage page separates the four that produce this message. If the bytes are being inflated between your disk and the server, that measurement is here. If the rejection happens after decoding rather than before it, the decoded-buffer page is the one to read.
The boundary this page can defend, measured: the same 84,394-byte file returned 84,394 bytes at a 300 KB target and 50,679 bytes at a 50 KB target, with the pixel count unchanged in the first case and cut to 6.4516% in the second. Which of those two results is correct for your form is decided entirely by the unit in its error message — and if the message has no unit, by the form's own published limit, which is either in the table above or not published at all.