PDF won't upload to a government portal: fixes

A government portal will not accept your PDF: what is really being checked

The form on a portal is usually terse: "the file does not meet the requirements". The requirements themselves live in a regulation linked two screens away, and half the checks are not documented anywhere at all.

Here is what actually gets checked, and the order in which to fix it.

The requirements that are not next to the upload button

There are usually four checks, and the form keeps quiet about three of them.

The file format. Determined from the content rather than the extension, so a renamed photograph does not get through.

The weight. Portals keep tighter limits than mail services: ten megabytes per file is more common than twenty.

Whether text can be extracted. Many departmental systems index incoming documents and require a text layer. A scan without recognition is empty to them.

The legibility of the details. A formal criterion from the regulation: the stamp, the signature and the reference number must be distinguishable on screen. A human checks that one, and a refusal on those grounds arrives later than the rest.

Scan resolution: where legibility ends

Regulations that name figures at all usually speak of 200 to 300 dots per inch for documents carrying stamps. That is not a whim: a seal contains small text around its rim, and at a low resolution that text turns into a grey fringe.

Here lies the trap that gets already-compressed files rejected. Default compression brings the images inside a document down to 150 dots per inch and uses a profile built for viewing on a screen. For a report someone will read, that is plenty. For a document whose seal will be examined, often not.

The compression level governs how hard images are squeezed: low is built for print, medium for reading, high for the screen. The quality processing profile additionally lowers the chosen level by one step, that is, treats the file more gently.

Worth knowing separately: the resolution of black-and-white scans is never taken below 150 whatever you set. That is a guard against turning a line-art scan into mush, and it applies regardless of your setting.

How to prepare the document

1. Find the file requirements in the portal's regulation: format, weight, resolution. It is usually one paragraph. 2. Put each document into its own file if several are required. 3. If a text layer is needed, recognise the scan through ocr-pdf before compressing. 4. Compress with compress-pdf, setting the resolution to the requirement rather than the default. 5. Open the result and zoom the stamp to a hundred per cent. If the text around the rim reads, the document will pass. 6. Upload the file and wait for the status: some checks happen after acceptance.

One document, one file

The instruction "upload as a single file" nearly always refers to one document rather than to the whole package. A certificate, a contract and its annex go into separate fields in most regulations, and gluing them into one PDF earns a refusal on completeness.

The opposite mistake is just as common: a multi-page document uploaded page by page, because the scanner produced separate files. That is exactly what merge-pdf is for, in the order the original sheets follow.

The rule is simple: the boundaries between files should match the boundaries between documents, not the way the scanner happened to emit them.

Page orientation and how the reviewer will see it

A separate category of returns, where nothing is technically wrong with the file: the pages lie on their side or upside down.

The reason is that rotation in a PDF is stored not as rotated content but as a separate property of the page: "display this at such an angle". Different programs handle that property differently. Your viewer may honour the rotation and show the page correctly, while the reader built into the portal may ignore it and show the same sheet sideways.

So check somewhere other than where you worked. Open the finished file in a browser by dragging it into a new tab. A browser's reader behaves closest to what portals run.

If the pages really are wrong, rotate before compressing rather than after: compression rebuilds the document, and an extra pass over it serves no purpose.

What the portal sees in the file besides the pages

The reviewing system reads more than the image. Document properties travel with the file, and something unwanted regularly turns up there.

A document title left over from a template. The name of the employee who made the scan. An internal folder path. The name of an organisation that has nothing to do with this application.

None of those fields blocks acceptance, but all of them are visible to the recipient. If that is unwelcome, clear the properties with set-pdf-metadata and the clear-existing option turned on.

The file's creation date is visible too. For documents where dating matters, remember that the date in the properties belongs to the file rather than to the document, and a discrepancy with the date on the form occasionally raises questions.

Passwords and active content

Two causes of refusal that look equally mysterious.

An owner password. The document opens with no prompt but forbids copying its text. A portal that needs to extract text formally honours that ban and refuses the file. It comes off through unlock-pdf with an empty password field: there is nothing to type.

Active content. A PDF can carry scripts, embedded files and forms with actions. Departmental systems reject such documents outright, because they do not investigate what is inside. The tell: the file is refused instantly, with no mention of size or format.

Both are cured the same way: any processing rebuilds the document from scratch, and active content does not carry over into the result.

When the portal refuses without explaining

When the message is useless, work through the causes in order of likelihood.

Check the weight. It is the most common cause and the only one you can see immediately.

Check whether the file opens without a password and whether text can be selected in it. Two seconds, and it eliminates two classes of refusal.

Check that there is one document in the file. Completeness is checked separately from format, and a refusal on those grounds looks identical.

Rebuild the file. A pass through compression, or a merge of the file with itself, gives you a freshly assembled document with no inherited oddities. That helps more often than you would expect, because many refusals come from structural quirks invisible to the eye.

Only then is it worth writing to the portal's support: by that point you can say exactly what you have already checked.