File components

Use a file component when a person needs to provide a document, image or other supporting file. Ask for an upload only when it is necessary: requesting files adds effort, can exclude people who do not have a digital copy, and creates additional privacy and security responsibilities.

Tell people exactly what to upload

Use the label and hint to explain what file is needed, why it is needed, which formats are accepted, the maximum size, and what to do if they cannot provide it.

Example:

Upload your proof of address
Upload a clear PDF, JPG or PNG. The file must be smaller than 10 MB. If you cannot upload it now, you can provide it later using the reference in your confirmation.

Do not use a generic label such as “Upload file”. If more than one document is needed, use separate components with distinct labels unless the service explicitly supports multiple uploads and can identify each file afterwards.

Set file types and size limits

Limit accepted file types to formats the service can safely process. Set the file-size limit based on the smallest limit imposed by any downstream action, message or storage destination—not just the upload component.

flowchart LR
  A[Choose accepted document formats] --> B[Set a realistic file-size limit]
  B --> C[Check storage and downstream limits]
  C --> D[Upload representative files]
  D --> E[Confirm review and retrieval behaviour]

Test a permitted file, an unsupported type, a file just below the limit, one just above it, a filename with unusual characters, and a large file uploaded on a slower connection. Make the error message explain what the person can do next.

Protect privacy in image uploads

The component can resize large image files, strip image metadata and blur faces. These settings should follow the service’s privacy and operational requirements.

Image resizing can reduce file size and make storage or transfer more reliable.
Metadata stripping removes information such as GPS, camera and timestamp data from supported image types.
Face blurring can reduce unnecessary exposure of people shown in images where that supports the service purpose.

Do not enable image transformations casually. Check whether a downstream reviewer needs original resolution, metadata or an unblurred image, and explain any material processing in the service’s privacy information where appropriate.

File safety and document reconstruction

File handling may include malware scanning and, for supported document types, document reconstruction before storage. These controls reduce risk but do not replace a carefully designed upload requirement or safe downstream handling.

Where document reconstruction is enabled, test representative Word documents, spreadsheets and PDFs. Check that the rebuilt file preserves the information your service needs and that reviewers understand which file they are viewing.

Treat platform-managed scanning configuration as an operational control. Do not expose internal scanning behaviour or configuration details to people using the service.

Review pages and files

Choose how an uploaded file appears on a review page: filename only, a view link, or a download link. Select the least access necessary for the person to check what they have supplied. Ensure authorised reviewers can retrieve the file through the intended process.

An uploaded file is not a text value and cannot be pre-populated in the same way as an input field. If a person returns to a saved journey, test whether the previously uploaded file remains available and whether they can replace it when that is intended.

Conditional uploads

Use conditional validation when a file is mandatory only in particular circumstances. For a simple same-page follow-up, reveal the upload field from the relevant choice. For a whole evidence-gathering step, use a page flow condition.

When a person changes the answer that made a file relevant, ensure later actions do not use a now-irrelevant file.

Testing checklist

The label explains the exact evidence required.
Accepted file types and size limit match every downstream destination.
Errors for missing, oversized and unsupported files are understandable.
Image resize, metadata removal and face blurring have been assessed for the service need.
Any document reconstruction produces a usable output for reviewers.
Review-page links provide the right level of access.
Returned journeys handle existing and replacement uploads correctly.
Conditional upload rules do not pass irrelevant files downstream.

Related guidance

Bulk Data evidence and integrations

The validated CSV includes respondent corrections; the untouched upload is retained separately. Use Upload files to send a selected Bulk Data evidence version to a configured file store. API actions can send up to 25 MiB of combined raw files as Base64; larger files can be streamed through the Bulk Data download API. Submitted revision selection requires retained Response history.

Bulk Data files, submitted revisions and integration examples

Component Settings