File too large or unsupported format? Diagnose an upload failure

The error text is short and unhelpful: "File too large". But your file is 200 KB. You checked.

That gap between what the portal says and what your computer says is where most upload troubleshooting actually happens. Before you recompress anything, get two pieces of information: the exact error message, and the exact requirement it refers to. Then match them.

This guide is organised by the error text you are most likely to see. Find yours, read what it actually means, and start there.

"File too large" — and the KB/KiB trap

The single most common cause of a "my file is already under the limit" complaint is that two programs are using the same letters to mean different numbers.

In decimal, 1 KB = 1,000 bytes. In binary, 1 KiB = 1,024 bytes. Software built on the binary convention often labels its numbers "KB" anyway. So a photo editor that reports a file as "195 KB" may actually mean 195 KiB, which is 199,680 bytes — more than a portal counting 200,000 bytes strictly will accept, even though it looks smaller than the number on the form.

The numbers:

Label	Interpretation	Bytes
200 KB (decimal)	200 × 1,000	200,000
200 KiB (binary)	200 × 1,024	204,800
1 MB (decimal)	1 × 1,000,000	1,000,000
1 MiB (binary)	1 × 1,024 × 1,024	1,048,576

If a portal says 200 KB and rejects a file your software calls 199 KB, the portal is probably counting bytes strictly, and your file is over 200,000. AttachReady's 200 KB preset is 200,000 bytes — deliberately the stricter reading of the two, so that either interpretation is satisfied.

What to check first: the actual byte count, from a tool that states bytes rather than a rounded kilobyte figure. File preflight reports integer bytes and does not estimate from the filename.

The fix: compress to a target with some headroom rather than to the exact limit. Binary-size confusion also cuts the other way — aiming at 200,000 bytes satisfies a portal that meant 204,800, but aiming at 204,800 fails one that meant 200,000. Note too that the "size on disk" your file manager shows is not the file size; it is the space allocated to it on the disk.

"Unsupported format" — when the extension lies

Extensions are just letters at the end of a filename. Nothing enforces that they match the bytes inside.

A file named photo.jpg can contain HEIC data, which happens routinely when someone renames an iPhone photo to get past a form. The portal reads the actual bytes, sees HEIC, and rejects it. The name did nothing.

There is a second, sneakier version of this. Messaging apps — WeChat, WhatsApp, Telegram, and similar — often re-encode images in transit. The photo you uploaded was a JPEG at 3 MB; the one your friend received and forwarded might be a lower-quality JPEG or a WebP, at a different resolution, carrying a different filename. If you are working from a file someone sent you, you may not be working with the original at all.

What to check first: the real file type. Image inspection reads the decoded file and reports the format, dimensions and metadata rather than trusting the name.

The fix: convert properly. Image conversion produces a new file in the format the portal accepts, and the extension matches the new bytes. Renaming is not conversion — it changes nothing except how the file is labelled.

One more format edge worth knowing: converting a transparent PNG or WebP to JPEG flattens the transparency, because JPEG has no alpha channel. Transparent areas come out as a solid background colour. If the transparency carries information, keep a format that supports it.

"Invalid image dimensions" — size and shape are separate problems

Pixel dimensions and file size are independent properties. Making an image smaller in bytes does not change its width and height at all. Serious compression usually does the opposite: it reduces dimensions or discards detail, and the byte count follows.

Portals that state dimensions want exact values: 600 × 800 pixels, or an aspect ratio such as 3:4. They check the decoded image, not the file size.

What to check first: the real width, height and aspect ratio, plus any stated limits on each — some forms cap the width and the height separately.

The fix: resize to the stated dimensions. Do not stretch an image to fit a different aspect ratio; faces and text distort, and reviewers notice. If the shape is wrong, crop to the correct ratio first, then resize. And do not assume DPI enters into it — pixels and DPI are different properties, and editing a DPI metadata field does not add pixels.

"Too many pages" or "page count exceeds limit"

Page limits apply to the document you submit, not to each source file. This catches people merging.

If a form allows 100 pages and you merge a 60-page document with another 60-page document, the result is 120 pages. Every input was fine. The output is not.

What to check first: the page count of the finished file, not the inputs.

The fix: if the recipient genuinely needs all the content, there is no technical trick — you need a different arrangement, or a conversation with the recipient about what they actually want. If they do not need every page, select the pages that matter and drop the rest. That is a content decision, so make it deliberately rather than by trimming from the end.

Why a merged PDF can be bigger than the sum

While you are here: merging does not compress. It concatenates. Two 8 MB documents merge to roughly 16 MB. If the portal's byte limit is the other thing failing, merging made it worse, and you will need to compress the result or rebuild it from smaller parts. Related reading: combining images into a PDF.

"File appears corrupted", "cannot be read", or "encrypted"

This one needs a careful answer, because the fix is different depending on which it is.

Encrypted or password-protected PDFs cannot be opened by these tools. If a PDF asks for a password when you open it, or if its metadata says it is encrypted, treat it as out of scope. AttachReady rejects encrypted PDFs, and there is no password-removal feature to switch on. The only way forward is to obtain an unprotected copy — either from the application that created it, or from whoever issued it. A bank statement you downloaded and opened with a password may be locked even though your reader remembered the password for you.

A practical detail: many readers only ask for a password once and then remember it, so a document that opens with a double-click can still be encrypted on disk. To check, open its properties, or run it through PDF inspection, which reports the document's structural facts.

Genuinely corrupted files cannot be repaired here either. There is no PDF repair feature. If a file fails to open in two different readers, it is probably damaged. Go back to the source — re-download it, re-export it, or ask for it again.

"Appears corrupted" can also be a false alarm. Some validators reject PDFs containing features they do not support: embedded file attachments, JavaScript, or certain external actions. Those documents are perfectly readable, but they carry active content, and AttachReady rejects those too. Exporting a plain PDF from the source application usually clears it.

One thing that is not on this list: a digital signature. A signed PDF opens normally and processes normally. But compression, merging and page selection all rewrite the file, and rewriting invalidates the signature. Keep the signed original untouched and work on a copy.

When the file passes every check you can see

Sometimes the file is fine and the upload still fails. Work through these in order:

• The receiving site's own session. An expired login or a timed-out form shows up as a generic upload error surprisingly often. Reload, sign in again, and try once before changing the file.
• The browser. Some portals are validated only on a narrow set of browsers. Try the one the site recommends, with extensions disabled.
• The filename. Long names, accented characters, spaces, and symbols like # or & break some upload handlers. Rename to something plain — id-scan.jpg — inside the rules the site publishes.
• The network. A drop mid-upload can look like a rejection. Check whether the failure is instant or after a delay; instant failures are validation, delayed ones are often transport.
• The requirement changed. Portals update their limits. The number you copied last month may not be the number today.

What you should not do is recompress the file repeatedly. Each pass discards detail, and if size was never the problem, you are degrading your material for nothing.

Getting help with an AttachReady error

If the failure comes from AttachReady rather than the receiving site, the troubleshooting and error codes page covers unsupported formats, unmet byte targets, expired files, quota errors and API authentication failures.

When you contact support@attachready.com, include the tool URL, the approximate time, and the error code or requestId. Never send API keys, passwords, or identity documents. A synthetic example that reproduces the problem is more useful than your real materials, and safer for you.

Finally, keep the boundary in mind: these tools verify technical requirements. When the file passes everything measurable and the recipient still rejects it, the remaining reason is on their side — a policy, a form field, or a rule they have not published. That is a question for them, not another compression run.