use UI

File Dropzone

Also called drag and drop upload, file uploader, drop area, upload zone

An area that accepts files dropped onto it, alongside a control for choosing them.

Example

Drag files here

PNG, JPEG or PDF · up to 5 MB each · 4 files maximum

Tab reaches “Choose files” and opens the native picker — there is no keyboard equivalent of a drag, so the button is not a fallback, it is the control. The rules are printed before anything is dropped, and every rejection says which file and why.

When to use it

  • Files are already visible somewhere else — a desktop, a folder, another tab — and dragging saves a dialog.
  • Several files arrive at once and the drop is one gesture instead of several.
  • The upload is a main action on the page, so the area can be large enough to be an obvious target.

When not to

  • The upload is one small field in a long form. A plain file input is smaller, faster and already understood.
  • The primary device is a phone. There is no dragging between apps; the button is the whole interaction.
  • You cannot afford the validation work. A dropzone accepts anything the OS hands it, so type, size and count checks are not optional.

Trade-offs

  • The fastest path when the file is already on screen — no dialog, no navigation.
  • Multiple files in a single gesture.
  • The area doubles as a place to show what has been added, and what is still missing.
  • Invisible affordance: nothing about a rectangle says it accepts a drop until something is dragged over it.
  • Useless without a pointer, so it can never be the only route.
  • Silent failure is common — an unsupported file is dropped, nothing happens, and no one is told why.

Accessibility

What this pattern needs in order to work for everyone.

Keyboard
  • There must be a real `<input type="file">` reachable by Tab, or a button that opens it. Dragging has no keyboard equivalent to build.
  • Do not hide the input behind a `div` with a click handler — a visually-hidden input inside a `<label>`, or a button that forwards the click, keeps the native picker and its keyboard support.
  • Every added file needs a named remove control: “Remove report.pdf”, not a column of identical crosses.
Roles and state
  • Announce what happened. Files added, files rejected and the reason all belong in a polite live region — a silent rejection is indistinguishable from a broken page.
  • State the rules before the drop, not only after a failure: accepted types, maximum size, how many.
  • The drag-over state must not be colour alone; change the border and add text, because the highlight is the only signal that a drop will land.
  • Errors belong next to the control and referenced with `aria-describedby`, so they are read when focus reaches it.
Focus
After a drop, leave focus where it was — the user's hand is on the mouse. After picking through the dialog, focus returns to the button, and the new files are announced rather than focused.

In the wild

  • GitHub issue attachments — Drop, paste or click — three routes to the same input, with the rules written under the field.
  • Figma import — Large drop target with an explicit button, and per-file progress and errors after the drop.