Validate demo uploads beyond the file input accept attribute

Treat a file input's accept attribute as a picker hint and validate the selected upload separately before a hackathon demo depends on it.

A prototype that requests a CSV can still receive the wrong kind of file. The browser's chooser helps the user find an expected format, but the application needs its own rules for size, contents, and what happens after rejection. A successful chooser interaction does not prove the file can be processed.

Describe the expected selection

Use a visible label and a narrow hint that matches the formats your implementation supports. This example names CSV explicitly; it does not promise to import spreadsheets or every text file.

<label for="demo-data">Demo data (CSV)</label>
<input id="demo-data" type="file" accept=".csv,text/csv">

MDN's accept documentation states that the attribute guides selection rather than validating the file type. It also calls for server-side validation. A filename extension or client-provided media type alone is not a trustworthy security boundary.

Check the product contract

For a local rehearsal, write down the accepted column names, encoding assumptions, and a size limit that your team has actually chosen. Explain that limit in the UI. Do not invent a universal CSV maximum or silently accept a file that the parser cannot handle.

function checkSize(file, maximumBytes) {
  if (!file) return 'Choose a file first.';
  if (file.size > maximumBytes) return 'File exceeds this demo limit.';
  return null;
}

This helper only checks presence and size. It does not validate CSV syntax, required columns, or whether the upload is safe. Use a CSV parser that handles the dialect your product supports, and validate the parsed structure before adding data to the visible results.

Rehearse rejection without losing the user's work

Prepare fictional fixtures for a valid file, a file missing a required column, a malformed file, an oversized file, and an empty file. Try cancelling the chooser as well. Keep the previous valid data visible until the replacement passes your checks, if that matches the product's intended behavior.

For every rejected fixture, show a specific reason and let the user choose another file. Confirm that the loading state ends, the error is readable, and the next valid upload succeeds. A presenter should not need to reload the entire app after one mistaken selection.

Apply authorization and validation again wherever files reach the server. Keep the demo fixtures free of real identities. The English Stavleak hackathon catalog can help you find a challenge; read that event's data rules before bringing any external dataset into the project.