The short answer
Whizi caps a single attachment at 10 MB and all the attachments on one prompt at 20 MB together, and the error string names which layer refused the file.
The caps, in one place:
| Cap | Value | Where it applies |
|---|---|---|
| Single attachment | 10 MB | Any file attached to a chat message |
| All attachments on one prompt | 20 MB | The prompt as a whole |
| Attachments per prompt | 4 | Enforced by the backend, on the final user message only |
| Files staged in the composer | 6 | The website composer |
| Direct image upload | 8 MB | The image upload route |
| Image uploads per minute | 10 | Per account, per UTC minute |
| Image uploads per day | 60 | Per account, per UTC day |
| Project pinned file | 10 MB, 10 files | Per project |
| Text in one chat message | 100,000 characters | Includes text extracted from your files |
Attachments cost no credits, so a refused upload costs you nothing and neither does a successful one.
The file is too large
Four different strings can appear on a size refusal, depending on which layer caught the file.
| Message | HTTP code | Trigger |
|---|---|---|
File {name} exceeds 10MB limit. Please upload a smaller file. | none, a website toast | You picked a single file over 10 MB through the attach button |
One or more files exceed the 10MB size limit. Please upload smaller files. | none, a website toast | You dropped files and at least one is over 10 MB |
Attachments must be 10 MB or smaller. | 413 attachment_too_large | The backend refused the file, checked first against the declared length and again against the real bytes |
Attachments are limited to 20 MB per prompt. | 413 attachments_too_large | Each file is under 10 MB but they add up to more than 20 MB |
The {name} in the first two is filled in with your file name.
The declared length is checked before the real bytes are, so re-declaring a smaller size does not get a large file past the 10 MB check.
The fix for all four is the same: send less at once. Split a long PDF into the sections you actually want read and attach the section you are asking about. Only the most recent user message carrying attachments has its attachments forwarded to the provider, so attach the file to the message that asks the question rather than relying on one sent earlier in the conversation.
Directly uploaded images have their own, lower cap: Image is too large. Please upload an image under 8 MB. is HTTP 413 upload_too_large. It fires twice over, once on a declared Content-Length at more than twice the cap and again on the real file size at 8 MiB, so a mis-declared length is caught either way. Re-export the image at a smaller size or a lower resolution.
For project pinned files the cap is also 10 MB, with its own strings: {name} is over the 10 MB limit. as the website toast and Project files must be 10 MB or smaller. as HTTP 413 project_file_too_large.
The file type is not accepted
Three different allowed-type lists exist, because chat attachments, direct image uploads and project pinned files are three different paths.
| Message | HTTP code | What it accepts |
|---|---|---|
Choose an image, PDF, text, Markdown, CSV, or JSON file. | 415 unsupported_attachment_type | Chat attachments: JPEG, PNG, WebP, GIF, PDF, TXT, Markdown, CSV, JSON |
Unsupported image type. Please upload a JPG, PNG, WebP, or GIF. | 400 unsupported_image_type | The image upload route: image/jpeg, image/png, image/webp, image/gif |
Choose a PDF, Word, Excel, text, Markdown, CSV, or JSON file. | 415 unsupported_project_file_type | Project pinned files, which deliberately exclude images |
Unsupported file type. Please upload an image, document (PDF, Word), spreadsheet (Excel), or text-based file. | none, a website toast | The composer classifying a picked file |
{name} is not a supported file type. | none, a website toast | A picked project file that is an image, or otherwise unsupported |
The composer shows that unsupported-type toast when you pick a file through the attach button. Drag and drop stays silent on the same case, so a dropped file that never appears in the composer and produces no message at all is most likely an unsupported type. Pick it through the attach button instead and you will get the toast that names the problem.
GIFs are the one place the two paths disagree. The website composer rejects them outright with GIF files are not supported. Please upload a PNG or JPEG image., while the backend image upload route accepts image/gif. On the website, convert the GIF to a PNG or JPEG frame and upload that.
For anything else off the list, the fastest route is a format conversion: save it as PDF, CSV or plain text and upload that instead. The full accepted list is in supported file types.
The file does not match what it claims to be
Two checks run past the type list, and both produce their own message.
The file extension does not match its content type. is HTTP 415, code attachment_extension_mismatch on a chat attachment and project_file_extension_mismatch on a project file. It fires when the extension on the file name and the content type sent with it disagree.
The selected file does not match its declared format. is HTTP 415, code invalid_attachment on a chat attachment and invalid_project_file on a project file. This one is a signature check: the first bytes of the file are read and compared against the declared MIME type, so a file that has been renamed rather than converted is caught here.
The usual cause is a rename. Changing report.txt to report.pdf does not make it a PDF, and this check is what notices. Open the file in its own application and export or save-as the format you want, then upload the result.
Too many files, or too many uploads
Count limits produce their own messages, and they are not all the same number, because the composer and the backend count different things.
| Message | HTTP code | Trigger |
|---|---|---|
You can only upload up to 6 files per message. | none, a website toast | A pick or a drop would take the composer past 6 staged files |
Message {n} may carry up to 4 valid attachments, and only on the final user message. | 400 invalid_attachments | More than 4 attachments on a prompt, or attachments on a message that is not the last user turn |
Message {n} repeats an attachment. | 400 invalid_attachments | The same attachment id appears twice on one message |
Projects hold up to 10 files. Remove one first. | 409 project_file_limit_reached | An 11th pinned file on a project |
This project already holds 10 files. Remove one first. | none, a website toast | Shown before the upload even starts, when the list is already full |
Rate limits are separate from counts. Upload rate limit reached. Please wait a moment before uploading another image. is HTTP 429 upload_rate_limited, and it fires after more than 10 image uploads in a single UTC minute. The wait is a minute.
Daily upload limit reached. Please try again tomorrow. is HTTP 429 upload_daily_limit_reached, after 60 image uploads in one UTC day. The reset is on UTC midnight rather than midnight where you are. Project file uploads have their own ceiling of 10 per minute.
The upload worked but the file could not be read
When extraction of a PDF, Word or spreadsheet file throws, the upload itself succeeded and the failure is in reading the contents. Each format has its own message.
| Message | What it usually means |
|---|---|
Could not read {name}. The PDF may be corrupted or password-protected. | PDF text extraction threw. A password-protected PDF is the common case |
Could not read {name}. Please try re-saving the document. | Word extraction threw |
Could not read {name}. The spreadsheet may be corrupted. | Spreadsheet extraction threw |
Could not read {name}. Older .xls files are not supported. Please re-save the file as .xlsx and upload it again. | A legacy binary Excel file. The message is the fix |
Could not read {name}. | Plain text extraction threw |
No readable text found in this file, so the model cannot see it. | A project pinned file whose extraction produced nothing at all |
For a password-protected PDF, remove the password in your PDF reader and upload the unlocked copy. For an older .xls, open it and save as .xlsx. A scanned PDF that extracts to nothing is covered in chat with a PDF.
A file can also be read successfully and then trimmed. A single chat message is capped at 100,000 characters, and extracted file text counts toward it. When the extracted text does not fit, you see Your upload was too large, so only the first part of it was sent. Ask about a smaller section for full coverage. and the message itself carries the marker [Attachment truncated: the upload was larger than one message can carry, so the content past this point was not included.] at the cut. The model receives the text up to that marker and nothing after it, so an answer that reads as complete may be based on a partial document.
If the whole message is refused rather than trimmed, the backend returns HTTP 400 message_too_long with This message is {count} characters, over the 100,000 character limit. Attach a shorter file, or ask about one section at a time., where {count} is your actual character count.
The upload failed for no obvious reason
A handful of strings mean the upload never completed rather than being refused on its merits.
| Message | What it means | What to do |
|---|---|---|
Failed to retrieve session token. | Your session token could not be fetched before the upload call | Refresh the page and sign in again, then retry |
Failed to upload image: {statusText} | The image upload response came back not OK, with the server status text appended | Retry. If it repeats, the status text is what support needs |
Image URL not returned by the server. | The upload succeeded but the response carried no image URL | Retry the upload |
Could not upload your attachments. | The upload step threw in the side-by-side compare view | Retry, or send the same prompt in a normal chat |
Could not upload {name}. | A project file upload threw with no message of its own | Retry |
Invalid request and No file uploaded | HTTP 400 invalid_upload and no_file_uploaded. The request was not multipart/form-data, the form data failed to parse, or the body carried no file field | Retry the upload |
Media could not be stored. | The storage write returned no object | Retry once. If it persists, contact support |
Stored media metadata was invalid. | The stored media row could not be read back | Retry once. If it persists, contact support |
Something went wrong. Please retry. | HTTP 500. Any unhandled backend error | Retry once, then contact support |
A different family of messages means the file is gone rather than failing to arrive. One or more attachments could not be found. is HTTP 404 attachment_not_found, returned when an attachment id does not resolve to stored media owned by you. Media not found. is HTTP 404 media_not_found, and Media has expired. is HTTP 404 media_expired, returned once the stored object is past its retention window, which is up to 30 days. An old conversation can still hold a reference to a file that is gone, so re-upload it. The retention wording is on data and privacy.
- One attachment is capped at 10 MB, one prompt at 20 MB total
- The composer stages up to 6 files; the backend accepts 4 attachments per prompt
- Direct image uploads are capped at 8 MB, 10 per minute and 60 per UTC day
- Renaming a file does not convert it: the signature check catches it
- Drag and drop stays silent on an unsupported type, the attach button tells you
- GIFs are rejected by the website composer, so convert to PNG or JPEG
- Older .xls files must be re-saved as .xlsx
- A password-protected PDF must be unlocked before it can be read
- Extracted file text counts against the 100,000 character message cap
- Attachments cost no credits, so a failed upload costs nothing
Frequently asked questions
What does "Attachments must be 10 MB or smaller." mean?
The file you attached is over the 10 MB per-file cap, and the backend refused it with HTTP 413 and the code attachment_too_large. That string is the per-file cap only. Four files that are each under 10 MB but add up to more than 20 MB return a different string, "Attachments are limited to 20 MB per prompt.", with the code attachments_too_large. A fifth attachment on the same prompt returns "Message {n} may carry up to 4 valid attachments, and only on the final user message." with the code invalid_attachments.
Why does "The file extension does not match its content type." appear on a file that opens fine?
The extension check runs before the signature check, so a file whose extension disagrees with its declared content type is refused with this string and never reaches the magic-byte comparison that returns "The selected file does not match its declared format." The codes differ by upload path: a chat attachment returns attachment_extension_mismatch and invalid_attachment, a project file returns project_file_extension_mismatch and invalid_project_file, so the code in a network trace tells you which upload path refused the file.
I dropped a file into the chat and nothing happened, with no error. Why?
The most likely reason is an unsupported file type, and the drop path deliberately says nothing about it. The dropped file also never appears in the staged list, so there is nothing to remove and nothing on screen to explain the silence. Not every drop is silent: a drop that would take the composer past 6 staged files does raise a toast, "You can only upload up to 6 files per message.", on the same path where an unsupported type raises none.
How do I get past "Upload rate limit reached. Please wait a moment before uploading another image."?
You wait. It is HTTP 429, triggered by more than 10 image uploads in one UTC minute. The counter behind it belongs to the image upload route rather than to attachments in general, and the project file route keeps a separate one, so pinning files to a project and uploading images are not drawing down the same allowance. Whichever route you are on, the account also pays a shared ceiling of 30 requests per minute across every route, which a fast burst can reach before the upload limit does.
My PDF uploaded but the model says it cannot see the contents. What went wrong?
The upload landed and the extraction step is what failed. A password-protected or corrupted PDF produces the toast "Could not read {name}. The PDF may be corrupted or password-protected." A PDF pinned to a project whose extraction produced nothing shows "No readable text found in this file, so the model cannot see it." beside the file in the project instead. Remove the password and re-upload for the first case. The second case, a scan with no text layer, is covered on the chat with a PDF page.
Does upgrading my plan change anything about uploads?
It changes which models you can send a file to. Attachments cost no credits on any plan, so the upload itself is never the thing your plan is metering. Starter reaches four model identifiers, Pro adds 37 more on top of those, and every other model in the catalogue requires Powerhouse.