How to Send WordPress Form Uploads to Amazon S3

Every form on your WordPress site that accepts a file attachment, an application, a resume, a signed document, has to put that file somewhere. By default, it lands in a folder on your own server, and if nobody is watching, that folder just keeps growing until your host starts sending you storage warnings.

If you already keep files in Amazon S3 for everything else, storing form uploads in a separate spot on your server just means managing two systems instead of the one you already trust. And if the documents people attach are sensitive, applications, contracts, intake paperwork, you probably want them to land somewhere access controlled, not sitting in a public folder that anyone with the right link could open.

This is about routing the files a visitor attaches when they fill out one of your forms, not about moving your entire WordPress media library into S3 for image hosting. That is a different job, handled by different tools. Ninja Forms can send a form’s uploaded files straight to your S3 bucket the moment someone submits, with no separate connector plugin and no custom code required to get the basic setup running.

What you’ll need

To follow along, you’ll need Ninja Forms (free) and the File Uploads add-on, included with memberships or available as a standalone add-on. You’ll also need an AWS account with an S3 bucket already created, plus an access key with permission to write objects to that bucket. This walkthrough assumes that part is already in place.

If you have not built a file upload field yet, the complete guide to the File Upload field covers that groundwork first. If S3 is not what your organization already runs, Ninja Forms can route uploads to Dropbox or Google Drive instead.

How to send WordPress form uploads to Amazon S3 with Ninja Forms

Ninja Forms routes form uploads to Amazon S3 through a built in feature, not a workaround or a separate plugin. You connect your AWS credentials once, at the plugin level, then add a single action to any form that tells Ninja Forms which uploaded files to send there. From that point on, files upload to S3 automatically the moment someone submits the form.

Connect your WordPress site to Amazon S3

The S3 connection lives at the plugin level, so you only set it up once no matter how many forms end up using it.

1. In your WordPress dashboard, go to Ninja Forms, then File Uploads, then click the External Settings tab.
2. In the Amazon S3 Settings section, enter your Access Key, Secret Key, Bucket Name, and File Path, then save your changes.

File Path is optional. It’s a subfolder prefix inside your bucket, not something you need to fill in just to get connected.

One thing worth knowing before you move on: Ninja Forms marks Amazon S3 as connected as soon as all four fields are filled in. It does not check whether your access key and secret actually work until a real file tries to upload. If your credentials are wrong, or missing a permission, the settings screen will not tell you, you will only find out when you test a real submission, which is why the verification step later in this guide matters even if everything here looks connected.

If you would rather keep credentials out of the database entirely, Ninja Forms also recognizes them as constants in your site’s wp-config.php file: NF_FU_AMAZON_S3_ACCESS_KEY, NF_FU_AMAZON_S3_SECRET_KEY, NF_FU_AMAZON_S3_BUCKET_NAME, and NF_FU_AMAZON_S3_FILE_PATH. A constant always overrides whatever is entered on the settings screen, which is worth knowing if a connection looks right in the dashboard but is not behaving the way you expect.

Tell Ninja Forms which uploads go to Amazon S3

Connecting your AWS account does not route anything on its own. You still need to tell a specific form to send its uploads there.

1. Open the form and click the Emails & Actions tab.
2. Click the blue plus icon to open the Actions window.
3. Add the External File Upload action.

Open that action’s settings, and you’ll see a group labeled AMAZON S3, and a separate GOOGLE DRIVE group if you’ve connected that too, each with a toggle for every file upload field on the form. Turn on the toggle next to the field you want sent to S3.

If you’re expecting larger files, multi-page scanned documents or zipped folders, open the Advanced section inside that same action and turn on Background Upload. It hands the transfer off to a background process instead of making the visitor wait on your form’s confirmation while the file streams to S3. This toggle lives inside the action’s own settings, not the plugin’s general Advanced Settings page, so you won’t find it by hunting around Ninja Forms > Settings.

With the connection made and the action added, Amazon S3 becomes an available destination for any file upload field on this form. That’s the entire required setup. Everything below is about shaping how that routing behaves, not making it happen in the first place.

Your uploads are private by default, until you decide otherwise

Every file Ninja Forms sends to Amazon S3 uploads as private, with no configuration needed on your part. Nobody outside your WordPress site can open a file’s link just because they have it. The one setting that changes this is a single toggle called Use Public URL, in the same External Settings tab where you connected your S3 account.

With Use Public URL left off, the default, a file’s link only opens for someone logged into your WordPress site. Anyone else who clicks it, including the person who submitted the form, sees nothing. Turn Use Public URL on, and that changes for every externally routed file on your site, S3 included: anyone with the link can open it, no login required.

For something like a grant application intake form, where you’re collecting supporting documents you want to keep access controlled, the default setting does the job on its own. Reviewers logged into your site can open a file; nobody else can guess or stumble onto the link and get in.

If instead you’re running something more like a portfolio or resume submission form and want applicants to be able to reopen their own file later, you would need Use Public URL turned on, since Ninja Forms has no way to grant access to just the one person who submitted a particular file.

What happens to the copy still sitting on your server

By default, Ninja Forms keeps a local copy of every uploaded file on your own server, in addition to the copy sent to S3. That’s controlled by the Save to Server toggle in the file upload field’s own settings, and it’s on by default.

Leave it on, and you get a local backup alongside your S3 copy, useful while you’re first confirming everything actually works. Turn it off once you trust the connection, and Ninja Forms removes the local file once the S3 upload succeeds, so the same document is not stored twice.

Turn this off before you’ve confirmed a real submission actually reaches S3, though, and a failed or misconfigured connection means the file disappears from your server with no working copy anywhere. The person who submitted the form will not see an error, and neither will you unless you go looking. Confirm delivery first with a real test submission, then decide whether to turn off the local copy.

How to confirm your uploads are actually reaching S3

The only way to know your S3 connection is actually working is to submit a real test file through the form and check where its link points. A success message only confirms the submission was recorded, not that the file made it to S3.

Submit a test file through your published form, then open that submission in Ninja Forms and click the uploaded file’s link. If Use Public URL is off, you’ll need to be logged into your WordPress site to open it.

If the connection is working, the link resolves to an amazonaws.com address rather than your own site’s uploads folder. If it opens a URL on your own domain instead, the file never reached S3, even if the External Settings screen shows Amazon S3 as connected. That screen only confirms your credentials are filled in, not that AWS accepted them.

Turn server clutter into a working S3 pipeline

You’ve now got the two pieces that matter: an S3 connection made once at the plugin level, and the External File Upload action telling a specific form to use it. From there, the private-by-default setting and the Save to Server toggle are just about shaping who can open a file and whether a local copy sticks around, decisions worth making deliberately rather than leaving on their defaults without a second thought.