Why Government and Corporate Portals Keep Rejecting Your PDF

The short version: most portal rejections come down to a small, repeatable set of causes — the file is too large, it's missing a real text layer (common with phone-scanned documents), its pages aren't consistently oriented, or it's missing the archival metadata some systems specifically check for. None of these require guesswork to diagnose if you check for all of them at once instead of one rejection at a time.

The size limit nobody tells you upfront

A modern phone camera scanning a few pages easily produces an 8–15 MB file, but a meaningful share of government and legal e-filing systems cap uploads at 5 MB or less per document — some visa and immigration portals sit even lower. Court e-filing systems vary widely, with some federal systems allowing much larger files, so there's no single number to memorize; the only reliable approach is checking the specific portal's stated limit and leaving real headroom under it, since some systems enforce a stricter cap on the actual submission form than the one listed on their help page.

"Format not accepted" often means "not actually searchable"

A phone-scanned document is really just a photo of paper, saved as a PDF — there's no underlying text for a computer to read, only an image of text. Some portals specifically require a searchable PDF (one with a real, selectable text layer) and will reject a flat scan even though it opens and displays perfectly fine to a human. This is one of the least obvious rejection reasons, because the file looks completely normal when you open it yourself.

Mixed page orientation

Scan a multi-page document with a phone and it's easy to end up with most pages upright and one or two sideways, especially with double-sided pages or documents that mix portrait forms with a landscape table or chart. Some portals process every page assuming a consistent orientation and will flag or garble a document where that isn't true, even though nothing about the file itself is technically broken.

PDF/A, and why some portals ask for it specifically

A handful of systems, particularly ones built for long-term archival (court records, certain regulatory filings), specifically require or prefer PDF/A — a version of the format meant to render identically decades from now, which requires an embedded color profile and identifying metadata a standard PDF doesn't necessarily have. A document that opens fine everywhere else can still fail this specific, narrower requirement.

Checking for all of this before you upload, instead of after it bounces

Diagnosing these one rejection at a time is slow, since most portals only tell you about one problem per attempt. FormatDog's PDF Portal Prep-Suite runs all of these checks at once against a PDF you're about to submit: file size against an adjustable target, whether it declares PDF/A conformance metadata, whether every page shares a consistent orientation, and whether it has real searchable text rather than being scan-only — plus a check for whether the file is password-protected, since that alone blocks every other check from running. A single "Fix All" pass then resolves whatever's automatically fixable — rotating mismatched pages, adding PDF/A metadata, compressing to your target size — and hands back one corrected file.

What it won't silently promise to fix

Two things stay honest rather than automatic. "Declares PDF/A conformance" means the file has the real, verifiable mechanics every PDF/A file needs — it's not the same as passing a formal ISO 19005 certification check, which isn't something any browser-based tool can genuinely run. And a scan-only page with no searchable text doesn't get auto-converted into one — that needs OCR run first, since attempting to silently embed a text layer risks getting the alignment wrong. The tool flags it and points to our OCR Text Extractor as the next step, rather than guessing.