An upload form is a storage policy with fields attached.

The three settings that decide everything

Uploads are off by default, and that is the right default: a form that accepts files without a policy is a place for anything to arrive. Turning them on means answering three questions.

• What types? An allowlist per form. PDFs only is a password, not a limitation.
• How big? Five files of 25 MB each by default, adjustable per form up to the server ceiling.
• How long? Attachments expire with the retention window; the record stays.

<form action="https://freelyform.com/f/FORM_ID" method="POST" enctype="multipart/form-data">
  <label for="name">Name</label>
  <input id="name" name="name" required>

  <label for="document">Document (PDF, up to 25 MB)</label>
  <input id="document" name="document" type="file"
         accept=".pdf,application/pdf" required>

  <button type="submit">Upload</button>
</form>

Missing enctype is the classic bug

Without enctype="multipart/form-data" the browser sends only the file name as a text field. The submission succeeds, the record exists, and there is no file — which looks like a storage failure and is a markup mistake. Check the network panel for a multipart content type before investigating anything else.

Size limits are a courtesy, not a gate

Tell people the limit next to the input, in words: "PDF, up to 25 MB". A visitor who learns the limit after a three-minute upload is a visitor who does not try again. If large files are the normal case, the honest design is a link to a shared drive rather than a bigger field.

Where the files actually end up

Attachments live with the submission until the retention window closes. That is long enough to process a document and short enough to limit the damage from collecting documents nobody needed. Anything with a legal or contractual life beyond that belongs in storage you control, downloaded at the point of submission — ideally by a webhook that files it immediately.