File uploads are one of those form features that seem trivial until you actually ship one. A job application form needs a r\u00e9sum\u00e9 field. A support form is ten times more useful with a screenshot attached. A photo contest doesn’t work at all without one. And yet upload fields are also the single most dangerous thing you can bolt onto a WordPress form: done carelessly, they hand strangers a way to place arbitrary files on your server, leak personal documents through guessable URLs, and quietly wreck your email deliverability. In this guide we’ll walk through how upload fields work in the major form builders, and \u2014 more importantly \u2014 the safety checklist we run before any upload form goes live.<\/p>\n
Before adding an upload field, it’s worth being honest about whether you need one, because every upload field is attack surface. The use cases where they genuinely earn their keep:<\/p>\n
.pdf<\/code>, .docx<\/code>). This is the classic case \u2014 asking applicants to email documents separately kills your completion rate.<\/li>\n- Support and bug reports:<\/strong> screenshots and log files. A single
.png<\/code> of the error usually saves three rounds of back-and-forth.<\/li>\n- Photo and design submissions:<\/strong> contests, print orders, listings, insurance claims \u2014 anywhere the file is<\/em> the submission.<\/li>\n
- Verification documents:<\/strong> proof of purchase, ID checks. These carry the heaviest privacy obligations, which we’ll get to.<\/li>\n<\/ul>\n
If a plain text field would do the job \u2014 “paste a link to your portfolio” instead of “upload your portfolio” \u2014 take the text field. Fewer moving parts, fewer risks.<\/p>\n
How upload fields work in the major form builders<\/h2>\n
All the big builders can accept files, but the experience ranges from “drag a field in” to “read the documentation twice.”<\/p>\n
Contact Form 7<\/h3>\n
CF7 has a [file]<\/code> tag, and it works \u2014 but it demands care. You configure allowed extensions and a size limit directly in the tag (for example [file your-file filetypes:pdf|docx limit:2mb]<\/code>), and if you skip those constraints you inherit whatever the server allows. By default CF7 stores uploads in a temporary directory, attaches<\/em> them to the notification email, and deletes the file afterwards \u2014 so if the email fails, the file is simply gone. There’s no submission storage in core; most CF7 upload setups need an add-on to keep files at all. Workable, but it’s the setup where we see the most mistakes.<\/p>\nWPForms and Gravity Forms<\/h3>\n
Both have polished, native upload fields with type restrictions, size limits, and multi-file support \u2014 drag-and-drop in the modern styles. The catch is pricing: WPForms gates the file upload field behind its paid tiers<\/strong> (it is not in WPForms Lite), and Gravity Forms has no free version at all<\/strong>, so uploads start at their entry-level licenses. If uploads are your whole reason for choosing a builder, factor that in.<\/p>\nFluent Forms<\/h3>\n
Fluent Forms handles uploads with sensible controls \u2014 files stored with submissions, per-field type and size restrictions \u2014 though the upload field has historically sat on the Pro side of the fence.<\/p>\n
Trinity Forms<\/h3>\n
Full disclosure: Trinity Forms<\/a> is our own plugin, so weigh our praise accordingly \u2014 but the relevant fact here is simple and verifiable: the file upload field is in the free tier<\/strong>, with per-field type allowlists, size limits, and files stored with the submission rather than only emailed. We put it in free because we think “accept a r\u00e9sum\u00e9” shouldn’t be a paywall feature.<\/p>\nUpload features at a glance<\/h2>\n