Hacks VitaeAll tools
freecompressconvert
error cluster

Your file is too large to upload

Something has just refused your file for its size: a web form, an email, a portal, an app. This page tells you which limit you hit, how to get under it in about a minute, and what to do when the file will not go small enough.

Quick answer

Shrink the file, do not fight the form

// Answer

If it is a photo: reduce its pixel dimensions first with resize an image, then run it through compress at quality 85. If it is a PDF: run compress a PDF, and if that is not enough, split it into parts. Both tools work inside this tab, so a file that is too large to upload never has to be uploaded to be made smaller.

Diagnosis

Which limit did you actually hit?

Three different things can refuse a file for its size, and they behave differently. Knowing which one caught you tells you how much you need to save.

Where the limit livesWhat you seeCommon default
The page itselfRefused instantly, with a friendly message, before any transfer startsWhatever the developer chose. Often stated next to the button
The web serverThe progress bar runs, then fails near the end with a bare errornginx accepts 1 MB by default and answers 413 past that (nginx docs)
The applicationThe upload appears to finish, then the file is simply not therePHP ships with upload_max_filesize at 2M and post_max_size at 8M (php.net)
The mail systemA bounce, or the mail app refuses to attach the file at allSee email attachment limits

That 413 is a real HTTP status code. It was called "Request Entity Too Large" in RFC 2616, "Payload Too Large" in RFC 7231, and is "Content Too Large" in RFC 9110, so you will meet all three names depending on how old the software is. Either way it means the same thing: the server stopped reading.

The fix

Photos and images, in order of what saves most

  1. Resize before anything else. Open resize an image and set a maximum width. 1920 pixels is plenty for most things viewed on a screen; 1000 is plenty for most upload forms. This is the single largest saving available and nobody can see it.
  2. Then compress. Compress JPG and PNG shows the real before and after bytes for each file, including when the result comes out bigger. Start at quality 85 and drop to 75 if you still need room.
  3. Change format if the subject suits it. A photograph saved as a PNG is enormous for no benefit. PNG to JPG often takes such a file down by most of its size in one step.
  4. iPhone photo? It is probably HEIC, which many forms will not take anyway. HEIC to JPG converts it, and you can lower the quality in the same pass.
  5. Not sure which format wins. The image format benchmark encodes your own file as JPG, WebP and PNG and reports the actual byte counts, instead of quoting an average from somewhere else.
The fix

PDFs

  1. Compress it. Compress a PDF rewrites the file and reports what it saved.
  2. Split it. If one document is over the limit, split a PDF into page ranges and send them in sequence. Say in your message how many parts there are.
  3. Rebuild a scan. A PDF made of scanned pages is really a stack of photographs in a wrapper, and almost all of its weight is in those images. Compressing the images first and then using images to PDF gets far further than compressing the finished document.

One limit worth knowing: re-compressing every image buried inside an existing PDF is a much harder job than rewriting the file, and the PDF compressor here does only the second. For a heavy scan, the rebuild route above is the one that works.

Background

Why the limit is there at all

It is rarely meanness. A server that accepts any size of upload is a server that anybody can fill up, or tie up, from a laptop. The defaults are deliberately small for that reason: nginx's one megabyte and PHP's two are starting points chosen to be safe, and an nginx or PHP site that accepts larger files has had somebody raise them on purpose.

There are running costs behind it too. Storage, bandwidth and the memory used while a request is in flight all scale with what people send, and a request that takes two minutes to arrive is holding a connection open the whole time. A limit is the cheapest way to keep one visitor's giant file from degrading the site for everyone else.

Then there is the quiet reason: most files people upload are far bigger than they need to be. The limit is often doing the sender a favour.

The trap

25 MB on disk is not 25 MB in an email

If the thing refusing your file is email, the number in the error is not measuring what your file manager measures. Attachments are encoded into plain text before they travel, and that encoding makes them bigger. Google states its receiving limits are "the limit after encoding, which adds about a 37% increase" (Google Workspace admin help), and Microsoft describes the same effect as a 33% translation encoding increase on mail leaving its network (Exchange Online limits).

The practical version: aim about a quarter under whatever number you were given. A 20 MB file can fail a 25 MB cap. There is more detail, and a table of who allows what, on email attachment too large.

Last resort

When it still will not fit

  • Send a link instead of a file. Gmail does this for you automatically once you cross its limit, and Gmail's and Outlook's own help pages recommend it. A link's ceiling is far higher than an attachment's (Outlook.com allows 2 GB from OneDrive).
  • Cut the dimensions further, not the quality. At low quality settings a JPG starts showing blocky patches in skies and skin; where that begins depends on the encoder and the picture. Going from 1920 pixels wide to 1200 costs almost nothing anyone will notice and saves considerably more.
  • Send fewer files. Twenty photos as twenty attachments will usually breach a limit that one combined PDF, made with images to PDF and then compressed, sails under.
  • Crop. Half a photograph is half the pixels. Crop an image to the part that matters.
  • Ask what they actually need. Identity checks, insurance claims and job applications almost never need a 12 megapixel original. They need it legible.

One thing worth knowing before you hand a large original to a stranger's server to shrink for you: the whole reason this site works the way it does is that a file that is never sent cannot leak. If the file is a payslip, a passport scan or a contract, that matters more than a few megabytes.

Related

If the size was not the problem

FAQ

Frequently asked questions

Reduce its pixel dimensions. Quality sliders get the attention, but a phone photo four thousand pixels wide, being shown in a thousand-pixel box, is carrying sixteen times the pixels anyone will see. Resize it first, then compress. The two together usually take a file under any ordinary form limit.
Because the limit is on the server, not in the page. Your browser sent the whole file, the server counted the bytes as they arrived, and it stopped once the total passed what it was configured to accept. The page had no way to know in advance. A form that rejects a file instantly is checking the size in the browser instead.
Renaming does nothing at all; the size is the same. Zipping helps only if the contents are compressible. A text file, a CSV or a folder of documents can shrink a lot. A JPG, a PNG, an MP4 or a PDF full of photographs is already compressed, so a ZIP of it usually saves a percent or two and may add a little.
Yes, and it is often the right answer for a long scanned document. Split it into page ranges, send them in sequence, and say in the message how many parts there are. If the receiving system will only accept one file, compress harder or reduce the scan resolution instead.
No. Everything on this page runs inside your browser tab, on your own processor. A file that is too large to upload never has to be uploaded to be made smaller. You can confirm it by opening your browser Network tab while you work, or by switching off your Wi-Fi first.

Last reviewed 2 October 2026

Ask an assistant about this page

Opens in a new tab with this page and the question already filled in.