Learning objectives
Configure a file-upload form; choose explicit button types; explain why client controls and hidden fields cannot authorize an operation.
Prerequisites
Understand forms, HTTP submission methods, names, values, and the distinction between client and server responsibilities.
A file picker is only the beginning
A file input lets a person choose files that the browser is allowed to expose to the page. The accept attribute suggests file types to the picker, such as image/* or a list of MIME types and extensions. It is a usability hint, not a security filter. A determined client can send a different file type regardless of what the picker offers.
Multiple permits more than one selected file. Capture can hint at a capture device in some mobile workflows, but support and interpretation vary. Do not promise that the camera will always open. A real upload form using POST needs multipart/form-data encoding so the request can carry file data and ordinary fields together.
The server must enforce its own size limits, inspect content, choose safe storage, control access, and avoid executing uploaded files. A filename supplied by a user is untrusted data. Client previews can improve confidence but should not imply that a file has already been uploaded, checked, or permanently saved.
Buttons have different jobs
A button inside a form can submit it by default, so write type="button" for an action that should stay on the page. Use type="submit" for the main submission. A reset button restores controls to their initial values; it does not necessarily clear every value to an empty string. Reset is easy to trigger accidentally, so omit it unless the workflow has a convincing need.
Input also has submit, button, reset, and image states. A button element can contain richer phrasing content and usually gives more flexibility. An image submit control requires an accessible alternative and can submit click coordinates. These coordinates rarely fit ordinary application forms, so choose a normal labeled submit button unless that behavior is specifically needed.
A submitter can override form properties with attributes such as formaction and formmethod. This allows separate Save draft and Publish operations, but the server must validate which operation is allowed. The visible button label does not grant the user permission to perform it.
Hidden does not mean protected
A hidden input carries a value without showing an editable control. It can be useful for record IDs or workflow tokens, but anyone controlling the browser can modify it. A hidden price must never determine a final charge, and a hidden account ID must never establish ownership. The server derives or validates trusted facts from its own data and authenticated context.
The same distinction applies to readonly and disabled. Readonly fields remain available for submission in applicable controls, while disabled fields are ordinarily omitted. Neither is a substitute for authorization or server validation.
Working example
<form method="post" action="/upload" enctype="multipart/form-data">
<label for="photo">Profile photo (JPEG or PNG)</label>
<input id="photo" name="photo" type="file" accept="image/jpeg,image/png">
<button type="submit">Upload photo</button>
</form>Another example
<form method="post" action="/drafts/save">
<input type="hidden" name="draft_id" value="42">
<label for="title">Draft title</label>
<input id="title" name="title" required>
<button type="submit">Save draft</button>
</form>Expected output
The first example opens a file picker and advertises its accepted formats. The isolated playground blocks submission, so no upload occurs. The second example illustrates the markup sent to a draft-saving endpoint; that server endpoint must be implemented separately before the form is published as a functioning service.
Common mistakes
Do not claim a successful upload merely because a file was selected. Do not trust accept, hidden values, or disabled controls as security boundaries. Do not add a reset control beside the primary action without considering accidental data loss.
Accessibility and browser notes
Name the selected-file purpose clearly and communicate limits before selection. A custom-looking file picker must retain keyboard and assistive-technology access to the native input. Progress and completion feedback should distinguish selection, transfer, processing, and failure.
Practice
Write a multiple-file document input that suggests PDF files and a submit button. State the server checks that remain necessary.
Review the solution and reasoning
<form method="post" action="/documents" enctype="multipart/form-data">
<label for="documents">PDF documents</label>
<input id="documents" name="documents[]" type="file" accept="application/pdf,.pdf" multiple>
<button type="submit">Send documents</button>
</form>Multiple permits more than one choice, while the name convention may be interpreted as an array by some server frameworks. The server still validates file count, size, actual content, storage location, and permission to attach files to the intended record.