My upload failed

Uploads fail for a small number of concrete reasons: the file is too big, the format is not accepted, the connection dropped part-way, or the file went somewhere other than where you are looking for it. The limits themselves are in supported files and limits; this page is about what to do when an upload does not work.

The Upload button stays greyed out

Cause. A staged file is over 10MB. The size check runs in your browser before anything is sent, so nothing is uploaded and nothing is lost — the file is listed with its size and the note — exceeds 10MB limit, and the button stays disabled while it is in the list.

Fix.

1. Remove the flagged file from the list with its remove control. The button comes back as soon as no oversized file remains.
2. Make a smaller version. A scan is usually large because it was captured at a higher resolution than anyone needs: rescan at 200–300 DPI, or use your scanner or PDF tool’s reduce file size export.
3. If the document genuinely runs long, split it into parts under 10MB and upload each. Files on the same requirement can be reordered and combined afterwards — see uploading documents.

My file is not in the file picker, or is refused

Cause. The picker is filtered to the accepted extensions: .pdf, .jpg, .jpeg, .png, .doc, .docx. Anything else is greyed out or hidden by your operating system’s file dialog, which is why the file appears to be missing rather than rejected.

The most common case is an iPhone photo saved as HEIC, which is not on the list.

Dragging a file onto the drop zone bypasses that filter. The file stages, the upload runs, and the rejection comes back from the server instead — so check the extension yourself when you drag rather than browse.

Fix. Convert first, then upload:

• iPhone photos — set Settings → Camera → Formats to Most Compatible so new photos save as JPG. For a photo you already have, use the share sheet to export it as a PDF, or email it to yourself, which converts it.
• Anything else — print or export to PDF. PDF is the safest format: it survives being combined with other files and it keeps page order.

Only one of the files I dropped was picked up

Cause. Not every drop zone takes more than one file. Where the screen is set up for a single document, dropping a handful hands over only the first file in the batch and quietly ignores the rest — the list then shows one file where you expected several.

Fix. Add the files one at a time, or use the multi-file upload area on a case requirement, which stages every file you drop and lists them all with their sizes before you select Upload.

The same file will not add twice

Cause. The staging list de-duplicates on file name and size. Picking the same file again — or picking it once by browsing and once by dragging — adds nothing, because it is already staged.

Fix. This is working as intended. If you genuinely need two different documents that happen to share a name, rename one before uploading. Naming files for the person who will read them (passport-bio-page.pdf rather than IMG_4471.jpg) avoids the collision entirely.

The progress bar sits still

Cause. Files upload one at a time, not in parallel, and the counter reads Uploading X of Y…. A large file early in the list holds the counter at the same number for as long as it takes to send, which on a slow connection looks identical to being stuck.

The second cause is a session that lapsed while the window sat open. When that happens the upload stops and the window shows Not authenticated rather than continuing.

Fix.

1. Give it time proportional to the file. Watch the counter rather than the bar — if X of Y advances at all, the upload is running.
2. If the window shows Not authenticated, close it, refresh the page, sign in again if you are asked to, and re-upload. Nothing was stored from that attempt.
3. On a phone, stay on the tab. Switching apps mid-upload can suspend the transfer.
4. If a file fails with a network error, only that file fails — the ones before it are already stored, and the ones after it still run.

The window closed but not every file is there

Cause. The upload window closes as soon as at least one file has been stored. If some files in the batch failed — one was too large, one hit a network error — the successful ones are saved, the window closes, and the failures are not restated afterwards.

Fix. Compare the file list on the requirement against what you meant to upload, and re-upload anything missing. Uploading the same file a second time is safe: it becomes another file on the same requirement, which you can remove from the document viewer if it turns out to be a duplicate.

Check the list before you leave the screen

The moment to notice a missing file is right after the window closes, while you still remember what was in the batch. The requirement’s file list is the record — not the upload window.

The file uploaded, but it is not on my Documents page

Cause. Three different things produce this, in order of how often:

• The folders are collapsed. The Documents page opens with everything closed. Expand the case, then the applicant, to reach the file rows.
• The file was never attached to a requirement. Documents lists files attached to a document requirement on an application, plus the forms Lexpoint generated. A file that is not on a requirement has nothing to be listed under.
• The case is archived. Archived cases are left out of the page entirely.

The Documents page is also read-only — there is no upload control on it, by design. Files enter the vault by being attached to a requirement on the case they belong to.

Fix. Open the case, go to the application’s Documents tab, and check the requirement you uploaded against. If the file is there, the vault will list it under that case and applicant. If it is not, upload it again from the requirement. See your document vault.

The file is on the requirement but shows an unfamiliar status

Cause. A stored file is not a finished file. It shows Reading file while it is analyzed, then settles on a review status while it waits for a person to look at it. That is the normal path, not a failure.

Fix. Nothing, unless the status is Needs Changes — that one is asking you to act, and the reason is recorded with the file. The vocabulary is in document review statuses and review and verification.

Combining files was refused

Cause. The most common one is a password-protected or secured PDF, which cannot be merged with anything. The error names it: We couldn’t combine these PDFs. One or more may be password-protected or secured. Try exporting an unlocked PDF. Banks and government portals often issue statements this way.

Fix. Open the file, enter the password yourself, and re-export or print it to a new unprotected PDF, then replace the locked file with that. The other reasons combine is refused — too few files, an unsupported type, a read-only application — are listed in uploading documents.

What to bring to support

Open a ticket at my.lexpoint.io/app/tickets with:

• The case number and the name of the requirement you were uploading against.
• The file name, its format, and its size in MB.
• The exact error text. Upload errors are reported per file, in the form filename: reason — copy the whole line.
• Whether the file was dragged in or chosen through the browse dialog.
• Whether other files in the same batch succeeded.

Related

• Supported files and limits — the formats, the size cap, and what makes a scan usable
• Uploading documents — the full upload, replace, and combine workflow
• Your document vault — where stored files are listed and why
• Contacting support — what makes a ticket answerable fast