Contact form 7 file upload not working: find it

An upload has more gates than a text field. The file has to pass the browser, the tag's size and type rules, the server's own upload limit and the mail step, and each gate fails differently. A server limit can reject a large file before Contact Form 7 runs, so the form may show nothing from the plugin at all. An owner who tests with a small PDF on a laptop never reaches the gates a phone photo hits. The owner who checks the mail finds the message and no file, and assumes the upload never happened.

• Open the tag in the form editor and read its filetypes and limit options, then compare them with the photo's type and size.
• Try a small PDF on a laptop first, then the same photo from a phone, one at a time.
• Ask your host for the server's upload limit. A limit below your file size refuses the file early.
• In the form's Mail tab, confirm the upload tag is in the attachments box, not only named in the body text.
• After Send, read the console and the network tab. A failed upload request shows the status the server returned.

The browser reads the file first, and the form keeps its name on screen. That step only proves a file was picked. Next, the tag checks the size and type against its options, and a refused file usually shows a short message under the field, so the visitor can pick again. Then the server checks the upload against its own limit, which your host sets and which can be lower than the tag's. If the server refuses the file, the request can fail before Contact Form 7 writes any message.

The last gate is the mail. The plugin only attaches an uploaded file if the mail settings say to, and it cleans up the temporary copy afterwards. If the uploaded field is not listed there, the form can say the message was sent while your inbox receives the text without the file. Owners rarely look at this gate, because the confirmation looks the same either way.

An iPhone saves photos as HEIC by default on many models, and an Android phone can send a file type the list does not name. If the tag allows only JPG, PNG and PDF, a photo taken on the phone is refused under the field. The owner who tests with a PDF on a laptop never meets that refusal. The visitor on a phone sees a message that looks like a broken form.

Size works the same way. A single phone photo can be larger than a small default limit, and the tag refuses it under the field even when the server would take it. Raise the limit in the tag only when you also raise the server limit, or the file fails one gate later with no message. The number that matters is the one your host enforces, not the one written on the form.

Start with what the visitor saw. A message under the field means the tag refused the file, and the message names the rule. No message and a page that did not change points at the server or the mail step, so open the console and the network tab. A failed request with an error status points at the server limit. A successful request followed by an email with no attachment points at the mail settings.

A simulated visitor opens the same form, fills in the text fields, presses Send and reports the reply status and whether the form said sent. It cannot pick a photo from your camera roll, so test the file gate by hand: send the same photo from your phone and write down the message it gives. The run cannot read the mail log or your inbox, so check the attachment in your inbox yourself.

Hosts change upload limits and phone cameras change formats, so a form can refuse a photo after an update. Rerun the form after each change, then send the same small PDF and full-size phone photo by hand and check that the mail still carries the attachment. Owners behind a site password, or testing each preview deploy, repeat the run before a release.