How do I let customers attach photos to a service request on my website?

This page may contain affiliate links from which Blur Studio earns commissions.

For a lot of service businesses, a request form without a photo option means a second round trip: the customer submits the form, you reply asking for a picture, they have to go find and send it separately, and the whole thing takes three times longer than it should. Adding a file upload field closes that gap.

If your site is hosted on Netlify, the form itself is most likely already running on Netlify Forms, its built-in feature for collecting whatever a visitor submits without a separate form tool or account. That's relevant here because adding a photo field to a form like that is a small addition, not a new system to set up: the same form that already collects a name and a job description can take a file the same way, with no extra plan or service required.

Adding the upload field

A file input is just another form field, added the same way as a text or email field:

<form name="job-request" method="POST" data-netlify="true">
  <input type="hidden" name="form-name" value="job-request" />
  <label>Describe the job <textarea name="details"></textarea></label>
  <label>Photo of the job <input type="file" name="photo" /></label>
  <button type="submit">Send request</button>
</form>

Netlify handles the file the same way it handles the rest of the submission: it shows up in your Forms dashboard, attached to that entry, and if you've set up email notifications, the file typically comes through as a link you can click to view or download rather than a direct attachment.

The limits that actually matter here

Three numbers from Netlify's own documentation that you need to design around, not discover after a customer complains:

• 8MB maximum per submission, counting the text fields and the file together. A single decent-quality phone photo is often 2 to 6MB on its own, so one photo usually fits comfortably; two or three might not.
• One file per field. There's no multi-file picker on a single field. If you want to let someone attach up to three photos, add three separate file input fields, each clearly labelled ("Photo 1," "Photo 2," "Photo 3," or similar), rather than expecting one field to take several.
• 30-second timeout per submission. On a fast connection this is a non-issue; on a slow mobile connection with a large file, it's the kind of thing that causes a frustrated customer to give up mid-upload without you ever knowing they tried.

A practical workaround for the file-count limit: if photos genuinely matter a lot for your business (inspection reports, damage claims, before-and-after work), consider capping it at two fields rather than trying to accommodate every possible number a customer might want to send, and add a line of text telling them to email any additional photos separately. That keeps the form itself simple and reliable rather than trying to engineer around a hard platform limit.

What actually breaks, and how to avoid it

The most common real-world failure isn't a coding mistake, it's a customer on a phone trying to attach a full-resolution photo straight from their camera roll, which on modern phones can easily run 8 to 15MB on its own, already over the limit before any other field counts. A few practical mitigations: add a short note near the upload field ("photos under 5MB work best"), and if this becomes a recurring problem, consider whether the photo is actually essential to the first submission or could be collected in a follow-up message instead, where you're not constrained by a single request's size cap.

What I'd actually tell you

For the vast majority of "customer attaches a photo of the problem" use cases, this works fine without any special handling. Where it gets genuinely awkward is multiple large photos, video, or anything approaching a full set of inspection documentation, situations where you're really asking a contact form to do a job it wasn't built for. At that point, the honest answer is a dedicated upload tool or a short, separate process (even "text me the photos" for now) rather than stretching a simple form past what it comfortably handles.

When to skip this and use something else

If you're regularly collecting large files, videos, or many photos per request, a dedicated tool like Jotform's file upload feature (built for exactly this with higher limits) or simply asking customers to email attachments to a shared inbox will serve you better than pushing against Netlify's 8MB ceiling. Both of those options trade away the "it's already part of my site" convenience for higher limits, which is the right trade once file size becomes a recurring problem rather than an occasional edge case.

A worked example: a plumbing business adding a photo field

Say a plumbing business has been quoting jobs purely from a customer's written description, a workflow that frequently produces a quote that turns out to be wrong once the plumber actually arrives and sees the real scope of the leak or the pipe damage. Adding a single "photo of the issue" field to the existing request form, with a short note suggesting a reasonably sized photo, lets most customers attach one phone photo without hitting the 8MB limit, and gives the business a genuine first look at the problem before committing to a number. The practical change isn't dramatic from a technical standpoint, it's one new field in an existing form, but the effect on quote accuracy is real: a photo showing a corroded pipe fitting, say, tells the plumber immediately that this isn't the simple fix the written description implied, well before a technician's time gets booked against a wrong assumption.

Common mistakes with photo upload fields

• Not warning customers about the size limit before they try to upload. A customer who hits a submission error after already describing their problem in detail is a customer who might just give up rather than retry with a smaller file; a short note near the field heading off the problem is cheap insurance against losing that lead.
• Adding five or six photo fields "just in case" when most requests only ever need one or two. Each additional field adds visual clutter and a small amount of friction to the form for every visitor, most of whom will never use more than one or two of them; size the number of fields to your actual typical need, not a hypothetical maximum.
• Assuming the uploaded file always makes it through to whoever needs to see it. If email notifications only link to the file rather than attaching it directly, confirm that whoever reviews submissions actually knows to click through, rather than assuming the photo is automatically visible the same way the text fields are.

A second scenario: when one field genuinely isn't enough

Say an insurance-adjacent business needs multiple photos per claim, front, back, and close-up damage shots, which is a common enough need that it's worth planning for deliberately rather than discovering the limit mid-rollout. Three separate, clearly labeled file fields ("Front of item," "Back of item," "Close-up of damage") handle this within Netlify's one-file-per-field rule, as long as the combined size of all three photos plus the rest of the form data stays under the 8MB submission ceiling, which is tight but often workable if customers are nudged toward reasonably compressed images rather than raw camera output. Past three or four required photos, or if raw, uncompressed image quality genuinely matters for the claim, that's the point where a dedicated upload tool with a higher ceiling becomes the more realistic choice over continuing to stretch a basic form.

How I'd approach this

If a single photo field covers the real need, this is a five-minute addition to a form you already have, and Netlify's own upload handling is enough. Where I'd get involved is if photos are actually central to how you operate, inspection documentation, before-and-after proof, insurance claims, where you need reliable large-file handling, automatic compression, or a proper gallery view of everything a customer's sent over time. That's a genuinely different, more capable system than a contact form field, and it's worth building properly rather than fighting a form's built-in limits indefinitely.