21 CSS File Upload Buttons

The native <input type="file"> renders a browser-controlled button that CSS cannot reach — no pseudo-element gives you the button text, and its appearance differs across Chrome, Safari and Firefox. The universal pattern is to pair the input with a <label>: <input type="file" id="upload" class="visually-hidden"><label for="upload" class="btn">Choose a file</label>. Clicking a label activates its associated input for free, so you style the label as any button and the native control never shows. The critical detail is how you hide the input. display: none and visibility: hidden both remove it from the accessibility tree and from the tab order, so keyboard users can no longer reach the control at all — a real and common accessibility failure. Use the visually-hidden clip pattern instead: position: absolute; width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap;. The input stays focusable and announced, and you get a fully styled trigger. Then style .btn:has(+ input:focus-visible) or use :focus-within so the visible button shows a focus ring when the hidden input is focused.

The native control shows "No file chosen" until a selection is made, and once you hide it for styling you lose that feedback entirely — so you have to provide it. Listen for change on the input and read input.files, which is a FileList: const name = input.files[0]?.name ?? 'No file chosen'. For multiple files, input.files.length gives the count, and the friendly form is usually a count plus the first name rather than a wall of filenames. Two details make this production-grade. Format the size with a helper rather than showing raw bytes — (bytes / 1024 / 1024).toFixed(1) + ' MB' is what people expect. And put the filename in a live region with aria-live="polite" so screen reader users hear the selection confirmed; without it, the interaction completes silently for them. Long filenames are the other trap: a 90-character name will blow out a flex container, so pair min-width: 0 on the flex child with text-overflow: ellipsis, or middle-truncate so the extension stays visible.

Four events, and the two people forget are the ones that matter. dragover must call preventDefault() or the browser opens the file instead of letting you handle it — this is the single most common reason a dropzone "does nothing". dragenter and dragleave drive the visual state, but dragleave fires when the pointer crosses onto a child element too, so a naive implementation flickers constantly. Fix it with a counter that increments on enter and decrements on leave, showing the active state only while the count is above zero. drop also needs preventDefault(), then reads e.dataTransfer.files. Two production requirements beyond the mechanics. Drag and drop must never be the only way to upload — WCAG 2.2's Dragging Movements criterion requires a single-pointer alternative, so the zone should always contain a real clickable button that opens the file picker. And validate on drop: users can drop folders, 4GB videos or executables, so check type and size before doing anything, and tell them clearly when something is rejected.

Two approaches, and one is meaningfully better than the other. URL.createObjectURL(file) returns a blob URL synchronously that you can assign straight to img.src — it is fast, uses almost no memory, and is the right default. The catch is that it holds a reference until you release it, so call URL.revokeObjectURL(url) once the image has loaded or when the preview is removed; forgetting to is a genuine memory leak in a long-lived page where users upload repeatedly. The alternative, FileReader.readAsDataURL(), is asynchronous and produces a base64 string roughly 33% larger than the file, which for a 5MB photo means holding about 6.7MB of string in memory. Use it only when you actually need the data URL, such as embedding in a payload. For the layout, lock the preview with aspect-ratio and object-fit: cover so a portrait photo and a landscape one occupy identical space — otherwise the grid reflows as each preview loads, which is both ugly and a cumulative layout shift penalty. Always set the alt to the filename so the preview is not silent to screen readers.

Real progress requires XMLHttpRequest or a streaming fetch, and this surprises people: plain fetch() gives you no upload progress events at all. With XHR it is xhr.upload.addEventListener('progress', e => { if (e.lengthComputable) setPercent(e.loaded / e.total * 100) }). Note xhr.upload, not xhr — listening on the request itself reports download progress and will look stuck at zero. Drive the bar from a single custom property so the visual and the accessible value can never disagree: write --pct, scale the fill with transform: scaleX(var(--pct)) rather than animating width, and mirror the number into aria-valuenow on a role="progressbar". For large files, chunked upload is the honest pattern — slice with file.slice(start, end), upload sequentially, and compute overall progress as completed chunks plus the current chunk's fraction, which also gives you resumability. A determinate bar that jumps to 90% and waits is worse than an indeterminate spinner, because it promises information it does not have.

Five things, and the first is the one most custom uploaders get wrong. The native input must remain focusable — hiding it with display: none removes it from the tab order, so a keyboard user can never trigger the picker no matter how good your button looks. Use the visually-hidden clip pattern. Second, the visible trigger needs a real label association, either a <label for> or an aria-labelledby pointing at your button text. Third, focus must be visible on the styled element even though the focused element is the hidden input — :focus-within on the wrapper, or :has(+ input:focus-visible), both work. Fourth, every state change needs announcing through a polite live region: file selected, upload started, upload complete, upload failed. Silence after an action is the most common screen reader complaint about upload widgets. Fifth, per WCAG 2.2, drag and drop needs a single-pointer alternative, and any drag-to-reorder list needs keyboard equivalents — arrow keys to move an item satisfy both that and the general keyboard-operable requirement.

Client-side validation is for user experience only — it tells someone immediately that a 40MB file is too large instead of making them wait for a rejected upload. It is never a security control, because anything sent from a browser can be forged, so the server must repeat every check regardless. Set accept="image/png,image/jpeg" or accept="image/*" on the input to filter the OS picker, but treat it as a hint: it does not block drag-and-drop, and users can override it in the dialog. So validate in JavaScript too, checking file.type against an allowlist and file.size against your limit. Two refinements worth the effort. Do not trust the extension or the reported MIME type for anything sensitive — read the first few bytes and check the magic number if the file matters. And write error messages that state the limit and the actual value: "That file is 42MB. The maximum is 10MB" is actionable, whereas "Invalid file" sends people to support. Show the constraint before the user picks, not only after they fail.

The CSS ports unchanged; the JavaScript needs one structural change, because file state belongs in your component rather than in the DOM. In React the input is typically uncontrolled — you cannot set value on a file input for security reasons — so use a useRef for the element and useState for the selected File objects, rendering previews from state. Create object URLs inside a useEffect and revoke them in its cleanup, or you leak on every re-render. Vue uses ref plus onBeforeUnmount, Svelte onMount returning cleanup. All of these need 'use client' in the Next.js App Router since they touch FileList and drag events, and for the upload itself a Server Action or route handler receiving FormData is the current idiom. Two porting notes specific to uploads: clearing a file input requires setting input.value = '' directly, which React state cannot do for you; and the drag counter described above must live in a ref rather than state, since updating state on every dragenter causes a re-render storm.