PDF Upload Limits by Portal: 13 Real Systems and the File Size Targets That Actually Work

The fastest way to stop upload rejections is to stop treating every portal like the same system. A court filing platform, a university admissions workflow, and a recruiting ATS may all accept PDFs, but they enforce file size in very different ways. Some use a hard per-file ceiling. Others allow a large upload but fail later at parsing, malware scanning, or downstream processing.

The table below only includes systems with publicly documented limits that could be verified from official guidance pages. If a platform did not publish a reliable limit, it was left out rather than guessed. That matters here because this guide is supposed to save you time, not send you chasing an invented number.

• These are documented caps from official help pages, not estimated ranges.
• The same PDF can succeed in one system and fail in another because the platform logic is different.
• ATS and admissions systems often need a lower practical target than the headline cap suggests.

Government and legal systems are where people waste the most time, because the error message is usually short and the retry cycle is slow. HMCTS CE-File allows up to 100 MB per document, which sounds generous, but that does not mean a 96 MB filing is a good idea. A giant bundle is slower to review, slower to move through downstream systems, and more likely to be built from oversized scans that should have been cleaned up before filing.

The stricter planning and property systems are less forgiving. HM Land Registry allows 20 MB files through its online channels. The Planning Inspectorate appeals portal allows 15 MB per document. Islington planning uploads cap files at 10 MB. These are environments where the right move is usually structural before it is cosmetic. Split an evidence bundle into appendices before you crush it into a blurry single PDF.

For tax and local authority workflows, the tolerance is similarly narrow. HMRC Local Authority Portal guidance documents a 10 MB cap per document. In this category, you should optimize for predictable acceptance, not for squeezing every possible page into one upload. A text-heavy report scanned in grayscale at 150 to 200 DPI almost always performs better than a color phone scan exported at a much larger size.

• Use the posted legal or government cap as an outer ceiling, not as the actual target.
• Split appendices before over-compressing maps, exhibits, or planning drawings.
• For text-heavy submissions, grayscale at 150 to 200 DPI is usually enough.
• If the document is close to the portal limit, aim 15 to 25 percent lower on the final file.

Admissions and aid systems are small-limit workflows by design. UCAS restricts uploaded documents to 5 MB. College Board IDOC and CSS Profile guidance sets a 9 MB maximum. Those numbers already leave little room for badly scanned tax returns, shadowed phone photos, or multi-page packets exported in color when color adds no value.

These platforms also gate on more than size. UCAS states that documents may fail checks for file size, file type, password protection, or virus scanning. That means a file can be technically under 5 MB and still fail because the PDF is password locked or built in a way the system rejects. For families rushing to upload financial aid or admissions materials, that distinction matters a lot.

The right strategy here is conservative. For a 5 MB portal, aim for 2 to 3 MB. For a 9 MB portal, aim for 4 to 6 MB. Convert image sets into a single clean PDF, remove duplicate pages, use grayscale for tax returns and transcripts, and avoid photographing multiple pages in one shot. These systems reward clean document prep more than heroic last-minute compression.

• Treat admissions and aid uploads as small, clean scan workflows, not as archive storage.
• Password-protected PDFs are a common silent failure on admissions systems.
• A lower target gives you safety margin for scanner, validator, and upload quirks.

Recruiting systems create a different kind of failure. Greenhouse publicly documents that candidate uploads can be as large as 100 MB, but it also documents that resume parsing can fail on resumes larger than 2.5 MB. That means an applicant can technically upload a file and still lose the benefit of autofill and structured extraction. The attachment arrives, but the parser does not do the rest of its job.

This is why ATS compression advice should never be generic. A text resume should usually live comfortably below 1 MB, and often well below 500 KB. A visually designed resume with embedded graphics may still upload successfully, but it is more likely to fail extraction or create messy field parsing. In ATS workflows, smaller and simpler often wins over prettier and heavier.

The key lesson is to optimize for downstream use, not just for upload acceptance. If the platform reads the file into fields, your objective is parser-safe structure. That means real text, minimal graphics, plain fonts, and a file size that leaves no doubt. Portfolio material belongs in a separate attachment or a link when the employer allows it, not inside a bloated main resume.

• Upload success does not guarantee parse success.
• For resumes, practical parser-safe targets are often lower than 1 MB.
• Keep the main ATS resume simple and move visual work samples elsewhere when possible.

Healthcare platforms often enforce attachment limits at the individual file level rather than at the case level. NHS e-Referral guidance documents multiple files up to 5 MB each. Medical Appraisal Scotland SOAR documents a maximum of 12 MB per upload. NHS Jobs supporting documents in the offer workflow are tighter still at 1 MB per file.

That changes the compression strategy. A referral letter, clinic note, lab summary, and consent form do not need to live inside one PDF if the system accepts multiple uploads. In fact, splitting them usually preserves readability better than forcing everything into a single heavily compressed packet. Clinical text compresses well. Embedded screenshots and image-rich attachments do not.

If you are working inside a healthcare portal, separate text-heavy paperwork from pages that contain meaningful screenshots, diagrams, or photographs. Compression is still useful, but attachment boundaries matter more here than they do in many corporate systems. The portal may reject an oversized single attachment even when the overall case volume is modest.

• Check whether the portal limit is per attachment or per upload event.
• Text-heavy clinical paperwork usually compresses safely in grayscale.
• Keep image-heavy evidence separate when the system allows multiple uploads.

When a PDF is rejected, identify the portal family first: legal, government, admissions, ATS, financial aid, or healthcare. The correct target depends on category. Then check whether the platform limit is per file, per attachment, or per upload batch. After that, decide whether your real problem is file size or file structure. A bloated evidence bundle should often be split. A single text-heavy PDF should usually be compressed. A scanned packet should often be rebuilt or rescanned more cleanly.

You should also decide whether color is necessary. For tax returns, letters, transcripts, and typed forms, color is often wasted size. For maps, annotated plans, photographs, or certain medical pages, color may be necessary. Finally, leave margin below the cap. A file that lands exactly on the published limit is more fragile than a file that lands safely below it.

A good default sequence is simple: identify the system, confirm the real limit, split if the document contains distinct sections, compress if it is a single coherent file, check readability, and submit only after leaving margin below the cap. That sequence is more reliable than repeatedly lowering quality until the number looks small enough.

• Step 1: identify the portal class before touching the compression settings.
• Step 2: confirm whether the limit is per file, attachment, or upload batch.
• Step 3: split multi-part PDFs before over-compressing them.
• Step 4: verify readability after compression, especially for scans and IDs.
• Step 5: leave margin below the published cap instead of aiming at the exact number.