Where should we begin when “choose files” leaves “no file chosen” and ChatGPT still cannot see your file? Start with the upload control itself: most failures happen before the model ever receives anything. A desktop browser usually shows a native file input. That input resets after a reload, after a failed upload, and sometimes after a drag-and-drop miss. The fix is almost always a fresh attachment, not a longer prompt. This guide explains the upload pipeline, why the label lies, and the exact steps that recover a stuck “no file chosen” state in ChatGPT.
What the upload widget actually does
A file input is a browser control, not a chat feature. When you click “Choose files,” the browser opens its own picker dialog. Selecting a file does not send it anywhere. It only stores a local reference and fires a change event. The page then shows a filename or “no file chosen” depending on whether that reference exists.
ChatGPT layers its own uploader on top of that control. The chat app reads the selected file, checks size and type, then transmits it to a storage endpoint. Only after that transfer succeeds does the model get a parsed version. This split matters: a filename in the box means the browser accepted a reference, not that OpenAI received bytes. A reset label means the reference is gone, so nothing will be sent.
The reason the button resembles a 1990s web form is historical. Every browser ships a native file input, and frameworks reuse it for reliability and accessibility. Chat apps hide the default styling, but the underlying behavior is unchanged. So when the label says no file chosen, you are reading browser state, not model state. Plain language: the box is a receipt for a local pointer, and that receipt can expire.
The path from your disk to the model
Uploading looks instant but runs through distinct stages. Each stage can fail silently, and each failure resets the widget differently. Knowing the order narrows the diagnosis fast.
First is selection. The browser hands the page a File object with a name, size, and MIME type. Second is validation. The app compares the file against upload rules, including size caps and an allowlist of extensions. Third is transfer, usually an HTTP request to object storage. Fourth is processing, where the server extracts text, renders pages, or samples images. Fifth is context assembly, where extracted content is placed into the model's working window.
A file larger than the cap is rejected during validation, and the widget often clears. A file blocked by a corporate proxy fails at transfer, and the label may revert. A supported file that yields no extractable text passes transfer but contributes little at assembly. That last case is the professional caveat: a green upload is not a promise that the model can read the content. It means the pipeline accepted bytes, not that extraction produced usable text.
Size, type, and time limits in practice
Limits are enforced at different layers, and they are not identical across surfaces. Web chat, desktop apps, mobile apps, and workspace plans can impose different caps and different file-type allowlists. Treat any number you read as plan-specific and subject to change. The stable rule is architectural: there is a maximum file size, a maximum number of files per conversation, and a per-message total.
Text extraction adds its own ceilings. Very long PDFs may be truncated rather than rejected. Scanned pages may return empty text unless optical character recognition runs. Spreadsheets may import as flattened tables, losing formulas and multiple sheets. Videos and audio are usually not analyzed directly unless a transcription or vision path is enabled.
Time matters too. A file attached in one message is not globally available in every later conversation. Context windows are finite, and older attachments can fall out of the active window as a thread grows. A model that read your PDF an hour ago may no longer retain it. The practical takeaway: reattach the source when a long thread starts producing vague answers. That single habit resolves a large share of “it forgot my file” complaints.
| Failure signal | Likely stage | What it usually means | First move |
|---|---|---|---|
| “No file chosen” after picking | Selection or validation | Reference cleared or file rejected | Reselect, then check size and type |
| Filename shows, no reply | Transfer | Upload stalled behind proxy or network | Retry on another network |
| Upload succeeds, answer ignores file | Processing | Little or no extractable text | Test a plain-text version |
| Worked earlier, fails now | Context assembly | Attachment aged out of window | Reattach in current message |
| Mobile picker returns nothing | Selection | App lacks file permission | Grant access in device settings |
Edge cases that break the pipeline
Password-protected PDFs are a common culprit. The uploader receives bytes, but extractors cannot open the document, so the model gets an empty or partial payload. Encrypted archives behave the same way. Convert to an unprotected copy before uploading.
Scanned documents fail differently. A photographed contract is an image wrapped in a PDF shell. Without OCR, the extractor finds no text layer. The file uploads cleanly and contributes nothing. Running your own OCR first, or pasting the relevant text, produces a working result.
Filename and encoding quirks cause silent drops. Non-Latin characters, very long names, and unusual extensions can trip validation. Rename to a short ASCII filename and retry. Semicolons, slashes, and leading dots are frequent offenders.
Browser and extension interference is underrated. Privacy extensions, script blockers, and aggressive corporate filters can interrupt the upload request after selection. A private window with extensions disabled is the fastest isolation test. Mobile operating systems add another layer, because the picker may return a cloud placeholder rather than a downloaded file.
One counterintuitive detail: sometimes the file is fine and the message is the problem. Pasting a long prompt and attaching a file in the same turn can push the attachment out of the effective window before the model reads it. Attach first, confirm the filename persists, then send a short instruction in the next turn.
Misconceptions worth retiring
The biggest myth is that “no file chosen” describes the model's view. It never does. The label is a browser widget state with no knowledge of server-side processing. Clearing it tells you the local reference vanished, nothing more.
A second myth is that uploading equals reading. Extraction is lossy. Columns collapse, tables scramble, footnotes vanish, and charts lose their axis labels. A model summarizing a messy PDF is summarizing the extractor's output, not the original layout.
A third myth is that one upload persists forever. Attachments live in a conversation context, and that context has boundaries. Reattaching is not redundancy; it is maintenance.
Red flags that mean stop and change approach: The widget reverts to “no file chosen” on every attempt, on every browser, on every network. A corporate device blocks storage endpoints while ordinary browsing works. The file opens locally but extracts as empty text in any tool. The upload spinner never resolves past a few minutes. Sensitive documents would leave a regulated environment if uploaded.
If several of these appear together, the problem is environmental, not prompt-related. Chasing prompt wording will waste time.
Practical recovery steps and thresholds
Work from cheapest to most invasive. Each step targets one stage in the pipeline, so stop as soon as the filename persists and the model acknowledges the content.
Reselect the file and watch the label for five seconds. If it reverts immediately, treat it as validation or selection failure. Check size against your plan's stated cap and rename to a short ASCII filename with a standard extension. Test a small plain-text file. If text works and PDF fails, the problem is extraction, not upload. Disable extensions or switch to a private window to rule out interference. Switch networks, since proxy and firewall rules can block the transfer stage specifically. Reattach inside the current message when a long thread stops honoring the file. For scanned documents, run OCR locally and paste the text if the file still contributes nothing.
Thresholds to reconcile: file size caps, file-count caps, and context limits are three separate gates. Passing one does not imply passing the others. A small file can still fail type validation. A valid type can still exceed the per-message total. A successful upload can still age out of context. Diagnose the gate, not the symptom.
Limits of what this explains
Upload behavior is plan-specific and changes without notice, so no article can give you a permanent numeric cap. The mechanisms here are stable: selection, validation, transfer, processing, and context assembly. The numbers attached to those stages are not.
This guide also cannot diagnose account-level restrictions, regional availability, or workspace policy blocks. If every step fails on multiple devices, contact the provider's support with the exact stage where the label resets. That detail shortens the conversation considerably.
Finally, do not upload regulated, confidential, or identifying documents without confirming your organization's policy. The upload control will happily accept a file that policy forbids. That is a governance question, not a technical one, and it deserves an answer before the first click.