In HTML, what does the accept attribute on <input type="file"> actually do, and what does adding multiple change?

## What accept is for `<input type="file" accept="...">` communicates *intent* to the file picker. When the user opens the dialog, the browser passes the list along to the platform, and the dialog defaults to showing matching files. The accepted syntax is a comma-separated list of three kinds of token: ```html <!-- MIME types --> <input type="file" accept="application/pdf,image/png"> <!-- wildcard groups: the three defined ones --> <input type="file" accept="image/*"> <!-- file extensions, each starting with a dot --> <input type="file" accept=".csv,.tsv"> <!-- mixed, which is the practical form --> <input type="file" accept=".pdf,application/pdf"> ``` The syntax details matter and are a fair interview probe. An extension must begin with a dot — `accept="pdf"` is not an extension token and `accept="*.pdf"` is not one either. Only `audio/*`, `video/*` and `image/*` are defined wildcard groups; there is no `document/*`. Listing both an extension and a MIME type is common because platforms differ in which one they match well. ## Why it is not validation This is the point the question is really testing. 1. **The user can override the filter.** Most native dialogs offer an "All files" option, and the field still accepts what the user then chooses. 2. **Drag-and-drop can bypass it.** Dropping a file onto the control does not go through the dialog's filter in the same way. 3. **The type is guessed anyway.** The browser reports a file's type largely from its extension and OS association. Renaming `payload.bin` to `photo.png` makes the picker show it and makes it report an image type. 4. **There is no validity flag for it.** A file whose type does not match `accept` does not turn the control invalid in any way you can query — it is not part of the constraint machinery at all. So the correct mental model is: `accept` improves the odds that the user finds the right file quickly. It states nothing about the bytes. Whatever inspects the upload has to determine the real type from the content itself, and that inspection belongs somewhere the user cannot reach. ## What multiple changes ```html <label for="shots">Screenshots</label> <input id="shots" name="shots" type="file" accept="image/*" multiple> ``` Without `multiple` the control holds exactly one file, and every new selection replaces the previous one. With `multiple` the dialog permits a multi-selection and the control holds the whole set. The behaviour that surprises teams is that a *second* trip to the dialog still **replaces** the current selection rather than adding to it. "Add more files" — the pattern every upload UI wants — is therefore not something the element gives you; the page has to remember the earlier selection itself and present the combined list. Candidates who have shipped an uploader volunteer this immediately. ## capture `capture` is the mobile-specific companion: ```html <input type="file" accept="image/*" capture="environment"> ``` The value `environment` asks for the outward-facing camera and `user` for the front-facing one. It is a request, not a guarantee: a desktop browser ignores it, and a device may still present a chooser. Note that `capture` narrows the flow to capturing new media, which is wrong for a field where the user might legitimately want an existing photo. ## The value is not settable A file input's value cannot be assigned a path by script. Browsers permit clearing it only. This is a long-standing platform rule: a page must never be able to nominate a file from the user's disk without an explicit user gesture. It is worth knowing because it explains why "pre-fill the upload field with the file they chose last time" is not implementable in HTML. ## Labelling and appearance The file control renders as a platform button plus a filename readout, and its appearance is deliberately hard to change — again because the browser must keep the user's choice honest. The usual pattern is to associate a visible label with the input and style around the control rather than replacing it, keeping the real input in the accessibility tree so it stays keyboard-operable. ## The senior framing In one sentence: `accept` and `capture` shape the *choosing* experience, `multiple` shapes what the control can *hold*, and none of the three tells you anything reliable about what actually arrives. A candidate who says "accept restricts uploads to images" has described the demo; one who says "accept preselects a filter and I still determine the type from the content elsewhere" has described production.