Uploading documents customers will get wrong

Customers get document uploads wrong because most flows assume a desktop, a scanner and a fast link. Phones save HEIC photos, limits hide until upload time, and "Invalid file" explains nothing. Fixing document upload user errors is less about stricter validation and more about catching each mistake where it's cheapest — on the device, before the upload starts.

Key Takeaways

• Most document upload user errors come from defaults: phone cameras, HEIC photos, hidden size caps and vague "Invalid file" messages.
• Catch each error as early as possible — on the device, before the upload starts. Every later checkpoint costs more.
• State the rules (formats and size limit) before the picker opens; never let customers discover them by failing.
• Keep limits consistent across layers: NGINX rejects bodies over 1 MiB by default, and PHP silently empties requests past post_max_size.
• Re-validate server-side: real file type from content, real size, a malware scan, and storage outside the web root.
• Give every rejection a reason code and a named fix; vague errors push customers into email support loops.
• Documents are personal data: collect only what the workflow needs, and keep a retention policy you actually follow.

Why do customers get document uploads wrong?

Because most flows assume a desktop, a scanner and a patient customer. A phone photographs a certificate, saves it as HEIC or a multi-megabyte JPEG, and the portal rejects it after a full upload with the words "Invalid file". Document upload user errors come from defaults, not carelessness.

Four defaults do most of the damage. Pickers on phones open the gallery or the Files app depending on the accepted types, and customers get lost in their own camera roll. iPhones have saved photos as HEIC by default since iOS 11, and plenty of downstream tooling still won't open it. Scans arrive password-protected or corrupted. And size limits are usually enforced at the end of the upload, so the customer pays for the transfer before learning the rules existed.

What does each rejected upload actually cost you?

Every rejection buys a support ticket or an abandoned application. Staff re-request the file by email, wait, re-check and re-file it, and the customer's onboarding stalls for days. One bad limit quietly turns a five-minute form into a week-long exchange across three channels.

The pattern repeats. A customer hit with "Invalid file" retries blind, fails again, then emails the document to whoever they can find. Someone on your side downloads it, renames it, compresses it and uploads it themselves — unpaid processing work, repeated per customer. Meanwhile the number you care about, applications completed, drops for a reason nobody logged.

When does an upload flow need hardening — and when is a plain form enough?

Harden the flow when documents gate a workflow: customer onboarding, claims, loan files, admissions, HR paperwork. A one-off attachment to a monitored inbox can stay simple. The honest test is volume times consequence: the more customers pass through each week, and the longer a rejection stalls each one, the more the flow must absorb.

In Nepal most customers arrive on a phone over a patchy data connection, which raises the stakes: transfers take longer, networks drop mid-upload, and a retry has to be cheap. If you're still weighing whether a portal is worth building at all, start with the business case for a customer portal, then design the upload path second.

How do you build an upload flow that survives real customers?

Build the checks in the order the customer meets them: device first, server last. Declare the accepted formats before the picker opens, check size and type on the device, upload with visible progress, then re-validate everything server-side and show a preview the customer confirms. Each checkpoint removes a whole class of error.

1. Pick the smallest format set that works — PDF plus JPEG and PNG covers nearly every document. Declare it in the markup with the accept attribute and repeat it as plain text above the picker. Accept is a hint, not enforcement.
2. Check before you send. The browser's File API gives you file.size and file.type; block oversize or wrong-type files instantly, with a message that names the fix:

   input.addEventListener('change', () => {
     const file = input.files[0];
     if (file && file.size > 15 * 1024 * 1024) {
       // show the limit and stop here — before a byte moves
     }
   });

3. Accept phone photos instead of demanding scans, and downscale images with an image library before storage. Never make customers install tools to please your validator.
4. Upload with feedback: a progress bar, honest failure handling and automatic retry for dropped connections. For big files on mobile links, chunk the upload so a failure resumes instead of restarting.
5. Re-validate on the server: real size, real type read from the file's contents — never the filename or extension — and a malware scan before storage.
6. Show what you stored. Preview the document and let the customer replace or delete it until the step is submitted. Name stored files randomly so paths can't be guessed.
7. Log every acceptance and rejection with a reason code, so a week of traffic tells you the top cause — and you fix that first.

None of this needs exotic tooling; it's ordinary craft for a team that builds portals and internal systems for a living.

Which limits and settings actually matter?

Set one size ceiling and apply it at every layer, because each layer enforces its own. NGINX rejects request bodies over 1 MiB by default with a 413; PHP empties $_POST and $_FILES when a body exceeds post_max_size. Your form's idea of the limit means nothing until these agree.

# NGINX: reject oversize bodies before they reach PHP
client_max_body_size 25m;

# php.ini: post_max_size should sit at or above upload_max_filesize
upload_max_filesize = 25M
post_max_size = 26M

These are live server settings: run nginx -t before you reload, and change them in a quiet window. Type rules belong in the application:

$request->validate([
    'document' => 'required|file|mimes:pdf,jpeg,png|max:20480', // 20 MB
]);

How do you verify the flow works before launch?

Test with the devices your customers hold, not just your laptop. Upload an iPhone photo in HEIC, an Android camera shot, a 300 dpi scan, a password-protected PDF and a deliberately wrong file. Throttle the network, kill the tab mid-upload, then confirm every rejection names its fix.

• A photo taken from inside the flow, using the camera input.
• A real scan from a local photocopy shop — they behave nothing like laser prints.
• Zero-byte and renamed files, which only server-side checks will catch.
• A slow-network run: does a dropped upload resume, or restart from scratch?
• Rejection reasons in the logs — if "file too large" tops the list, your limit is wrong, not your customers.

Track two numbers from day one: uploads started and uploads completed. The gap is your error rate, and the reason codes tell you why.

Why do uploads fail silently in production?

Most silent failures live between layers, where one component's limit is another's assumption. NGINX returns 413 before PHP ever runs; PHP quietly empties the request when post_max_size is exceeded; a gateway timeout kills long uploads on slow links. Debug in order: browser status code, web-server error log, then application and storage logs.

• 413 in the browser's network tab — a proxy body-size limit; raise client_max_body_size, test, reload.
• An empty $_FILES with no error — PHP dropped a body over post_max_size; check the server log, not the form.
• Uploads dying around a minute — a gateway or FastCGI timeout; slow links need more time or resumable chunks.
• Stored files that won't display later — usually HEIC or a mislabelled extension; convert at intake instead.
• Intermittent mobile failures — the network switched mid-transfer; retry logic and chunking are the cure.

What does storing customer documents cost to run?

Storing files is cheap per gigabyte; the running cost hides in retention, backups nobody reviews and staff repeatedly downloading copies. Cold storage classes charge to retrieve, and egress mounts up. Review retention yearly, delete what the workflow no longer needs, and confirm current figures with your provider's own calculator.

Documents kept "just in case" are the worst line item: they cost storage, they widen your data-protection exposure, and they never pay for themselves. An annual retention pass is an afternoon's work that keeps both bills and risk flat.

How do you keep uploaded documents secure?

Treat every upload as untrusted input and as personal data. Re-check the real file type server-side, scan for malware, store files outside the web root or in private object storage, encrypt at rest, log who views what, and keep a written retention policy. Never collect a document the workflow doesn't need.

Identity documents are exactly what an attacker wants, so access control matters as much as intake: staff should see a file only when a task requires it, and every view should leave a trace. Two habits keep this honest — collecting only the customer data a process genuinely uses, and knowing where customer data actually lives across your hosting, backups and third-party tools.

Which upload mistakes do we keep fixing?

These five account for most of the upload pain we inherit. Each passes local testing because the tester uses a laptop, a fast link and a well-behaved PDF. All are cheap to fix before launch and expensive once customers have learned to email instead.

• Guessing limits instead of checking what real devices produce — a phone photo is a few megabytes untouched.
• Validating size only after the upload finishes, so the customer pays for the transfer to learn the rule.
• One error message for every failure, which forces customers to guess and retry blind.
• No replace path, so re-submissions pile up as duplicates nobody can delete.
• Testing only on desktop Chrome with tidy PDFs — the exact customers who never struggle.

What does a real failure and fix look like?

A composite from flows we've inherited: a lender's onboarding asked for a citizenship certificate, accepted only PDFs under 2 MB, and answered every failure with "Invalid file". Phone customers couldn't produce a valid file at all, so they emailed photos to a staff address — and staff uploaded them by hand.

Nothing was wrong with the validation itself; it aimed at the wrong customer. The rebuild took three changes: raise the ceiling and accept JPEG and PNG alongside PDF; downscale images before storage so phone photos fit; and rewrite every rejection to name the problem and the fix, with a reason code in the logs. Email submissions never vanished entirely, but they stopped being the main channel within a fortnight.

Which approach should you choose?

Match the machinery to the stakes. A plain form posting to your app handles low volumes well. Presigned URLs send the file straight from browser to object storage, so your servers never carry the bytes — AWS documents the browser-to-bucket flow. Verification services add fraud checks, at the price of a third party holding identity documents.

Approach	What it handles	Where it breaks	Fits when
Plain multipart form	Small files straight into Laravel, Node or similar	Big files tie up workers; retries restart	Low volume, internal teams
Presigned upload to object storage	Direct browser-to-bucket transfers; your servers skip the bytes	Needs careful expiry and access rules	Customer portals, files over a few MB
Resumable or chunked upload	Slow mobile links; failures resume instead of restarting	More moving parts to host and monitor	Large documents, weak networks
Verification service (KYC)	Fraud and authenticity checks on identity documents	A third party holds sensitive documents; per-check billing	Regulated onboarding

Start with the plain form. Move to presigned or resumable uploads when files grow or links worsen. Reach for a verification service only when regulation or fraud risk demands it — the simpler option wins until volume says otherwise.

In short: state the rules before the picker opens, check on the device, re-check on the server, explain every rejection, and keep only the documents the workflow needs. Those habits remove most document upload user errors without exotic tooling — they're design decisions, not features.

People also search for

• Does my business need a customer portal?
• How much customer data should a form collect?
• Where should customer files and records be stored?
• What should a website's documentation cover?
• How do you document an internal system for staff?
• Why design for mobile-first customers in Nepal?
• How should you tell customers when something breaks?

If your portal's upload step is leaking customers, or your team is still re-filing documents from email, our team can review the flow and rebuild it properly — you can see the kind of work we deliver in our portfolio. Tell us what's failing and we'll come back with a written plan, not a pitch.