- Published
- Byline
- GoHighLevel Partners Editorial
- Filed under
- GoHighLevel Automation
The limit is not a technical number — it is a decision about what you are asking people to send, and the default rarely reflects it.
File size limit on form uploads: choosing the ceiling deliberately
Adding an upload field to a form is easy. Choosing what it will accept is where the work is, and the size limit is the setting that most often gets left at whatever the builder suggested — which is fine until a customer with a modern phone photographs a document and the submission fails with a message nobody wrote.
The limit is not really a technical number. It is a decision about what you are asking people to send you, and it should follow from that rather than from the default.
Start from what is actually being uploaded
| What you asked for | What arrives | Implication for the limit |
|---|---|---|
| A photograph of a document | A phone camera image, often large, sometimes very large | A generous ceiling, or client-side resizing before upload |
| A scanned document | Usually modest, occasionally huge if scanned at high resolution | Moderate ceiling; expect outliers |
| Photographs of a job or property | Several images at once, each substantial | Per-file and total limits, and a cap on the number |
| A short video | Larger than everything else combined | Usually better handled outside the form entirely |
| A spreadsheet or export | Small, but the file type matters more than the size | Restrict types rather than worrying about the ceiling |
The first row is the common case and the one that catches people out. Asking a customer to “send a photo of the damage” produces whatever their phone produces, which is larger every year. A limit set to a comfortable number some years ago will now reject perfectly ordinary submissions from perfectly ordinary people.
Set the limit too low and you lose submissions silently
An upload rejected for size is not a mild inconvenience. The visitor has already committed effort, and they are often on a phone with the file in hand. What they see is a form that does not work, and a proportion of them will not try again.
Worse, the failure is often invisible to you. Unlike a validation message on a text field, an upload failure can leave no record at all — no partial submission, no lead, nothing to follow up. That is the argument for setting the ceiling higher than you think you need and constraining in other ways: by file type, by number of files, and by telling the visitor what to send before they choose.
Set it too high and you inherit different problems
- Slow uploads on a phone connection. A large file over a weak connection takes long enough that people assume the form has frozen. Show progress, and say what is happening.
- Storage that nobody prunes. Uploads accumulate per account, and large files are the reason a storage allowance disappears without anyone noticing.
- Files that are useless anyway. A very large photograph is not more informative than a moderate one for most purposes; it is just harder to move around.
- An attack surface. Any public upload field will receive things you did not ask for. Restrict the accepted types, and never serve uploaded files from a location that executes them.
The balanced position for most service businesses is a generous per-file ceiling with a strict list of accepted types and a modest cap on the number of files. That combination accepts the phone photograph without accepting a video nobody wanted.
Tell people the rules before they hit them
State the limit, the accepted types and the number of files next to the field rather than in an error message. That single change removes most upload failures, because the majority are people doing something the form never said it would not accept.
Then make the error message specific when it does fire: what was wrong, what is allowed, and what to do — the same standard as required-field validation. “Upload failed” tells the visitor nothing and generates a support enquiry. Where the form spans several steps, put the upload late rather than early, so a failure does not cost the visitor everything they had already typed; the wider trade-offs are in splitting a form across steps.
Where you can offer an alternative, do. A visitor who cannot upload a file should be able to send it another way rather than abandoning, and saying so on the thank-you step costs nothing.
The technical constraints you do not control
The number in the form builder is not the only ceiling. The platform, the hosting layer and any proxy in front of it each impose their own, and the smallest one wins. A limit configured at 50 and a platform maximum of 25 produces a failure the form’s own setting did not predict — so test with a real file at the size you intend to allow rather than trusting the setting.
Embedded forms add another layer. An upload inside a frame can fail for reasons entirely unrelated to size, and the symptom often looks like why an embedded frame clips — the form appearing to do nothing. Scripts loaded through code in the page header can also interfere with the upload control, which is worth eliminating before you assume the limit is at fault.
And the page itself pays a cost: an upload widget is usually heavier than the rest of the form combined, so if the field is on a landing page rather than a dedicated one, check what it does to the measurements in what a page speed score measures.
What happens after the file arrives
An upload that lands somewhere nobody looks is a wasted request. Decide in advance which record the file attaches to, who is notified, and what happens next — where a client portal is involved, the client portal file uploaded trigger is the mechanism that turns an upload into an action rather than a file sitting in storage.
Route on it as well. A submission with a file attached is often more serious than one without, which makes the presence of an upload a reasonable input to the intake rules described in routing and suppression. If several file types are accepted for different purposes, pair the field with a selector saying what the file is, built with the care writing a dropdown option list describes, so the automation knows what it received.
Finally, write down the retention position: how long files are kept, who can see them, and when they are removed. That belongs in your documented process, in the form structure, owners and exceptions describes, and keeping the index of what was received in a durable record outside the platform means you can answer a question about a file months later without searching an account you may no longer have.
Frequently Asked Questions
What file size limit should a form use?
Higher than feels necessary, paired with a strict list of accepted types and a modest cap on the number of files. The common case is a customer photographing a document with a phone, and phone images grow larger every year — a ceiling set comfortably a few years ago now rejects ordinary submissions.
What happens when an upload is rejected for size?
Often nothing you can see. Unlike a text-field error, an upload failure can leave no record at all — no partial submission and no lead to follow up. The visitor experiences a form that does not work, and a proportion do not try again.
What are the risks of setting the limit very high?
Slow uploads on phone connections that look like a frozen form, storage that quietly fills up, files larger than they need to be for the purpose, and a wider attack surface. Restrict accepted types and never serve uploaded files from a location that executes them.
Why does an upload fail even though it is under the configured limit?
Because the form builder’s number is not the only ceiling. The platform, the hosting layer and any proxy in front of it each impose one, and the smallest wins. Test with a real file at the size you intend to allow rather than trusting the setting.
Where should the upload field go on a multi-step form?
Late rather than early, so a failure does not cost the visitor everything they had already typed. State the limit, the accepted types and the number of files next to the field rather than leaving them to be discovered in an error message.
What should happen once a file arrives?
Decide in advance which record it attaches to, who is notified and what happens next. The presence of an upload is often a signal that a submission is more serious, which makes it a reasonable input to routing rules. Also write down how long files are kept and who can see them.
We build your GoHighLevel account for you
CRM, pipelines, funnels, SMS and automation — configured for your business, not left for you to figure out.
- Setup (one-time)$850
- Ongoing (per month)$38.80
No obligation quote · reply within 1 business day
This site is independently operated and is not officially affiliated with, endorsed by, or sponsored by HighLevel LLC. We do not receive referral commissions — this is our own flat-fee implementation service.