A file picker filter does not validate an image

The HTML accept attribute helps the file picker guide people towards suitable inputs. A form that requests JPEG and PNG can still receive an unsuitable file, so the receiving workflow needs its own validation.

Help people choose a suitable file with the picker filter, then check the selected input and explain any failure where it appears. A file that exceeds a stated byte limit needs a different message from a file that cannot be decoded.

Give the filter a specific purpose

Match the filter to formats your receiving workflow actually handles. Advertising a broad image category can leave people uncertain about why a photo selected from their library later fails. State the supported types beside the input too, where someone can read them before opening the picker.

A browser preview is useful feedback. It should have its own failure state and should not be described as proof that a server will accept the file. The preview and receiver may use different processing paths. A successful local display does not replace the checks required by the receiving service.

I work on Morphio, which has HEIC conversion tools. When an upload destination specifically needs JPEG, conversion can prepare a compatible copy of an HEIC photograph. Keep that advice separate from the upload control's validation: a link to a converter cannot establish that every returned file satisfies the receiver's rules.

Test messages with distinct inputs

Prepare a small set of files with known purposes. Include an allowed image, an image exceeding the form's stated limit, and an input the preview cannot decode. Check that the interface explains each outcome without discarding a previously valid selection unexpectedly.

Also inspect the path after an upload is rejected by the receiver. Preserve enough context for the user to correct the file. If the receiver reports a size limit, show the unit and whether the limit concerns a single file or the whole request.

Keep server-side validation even when the interface looks restrictive. The receiver must decide what it can process and store after the picker has helped someone choose an input. Document those responsibilities where future changes to the form will be made, so a cleaner picker is not mistaken for permission to remove receiving checks.

Reference: MDN's accept attribute documentation.