Prepare a PDF for Form or Portal Upload

How to prepare a PDF for upload

"A prepared file" sounds vague and means something quite specific: a document that clears the checks on the other side, needs no rework, and carries nothing with it that you did not intend to send. There are usually three or four checks, they are automated, and not one of them looks at what the file is called.

What the receiving side actually checks

The first row is worth memorising: the file extension means nothing. The format is identified from the content, so renaming a picture to `.pdf` will not help, and a genuine PDF with no extension goes through fine.

The fourth check is relatively recent and increasingly common: the receiving system wants to search across documents, and a scan is empty to it. Testing your own file takes a second: open it and try to select a line with the mouse. If the whole page highlights as one rectangle, there is no text layer.

The order of operations, and what each one takes

This is the part worth reading on for. Every operation preserves some things and loses others, and the order you run them in decides what actually reaches the recipient.

Hence the working order: assemble the document, fix the pages, recognise the text, and compress last. Compression goes last because any later operation inflates the file again. Recognition goes before compression because recognition reads the page image and compression degrades exactly that image.

The grayscale row explains a common misery. A document is turned grey to save on printing, sent into a form, and the form rejects it as a file with no text. The reason is that going grey redraws the pages as pictures. If the file is headed both to a print shop and to a form, prepare two versions.

The signing row explains another one: once a signature is stamped, the document title and keywords disappear from the properties, leaving only the author and the subject, into which the signature note is appended.

Document properties travel with the file

The title, the author and the keywords live inside the PDF and are carried across by almost every operation. The recipient sees them in the document properties, and something unwanted turns up there regularly: the name of the employee who prepared it, an internal working title along the lines of "draft for legal", a folder path from someone's disk.

Word and other editors fill those fields automatically from account settings. The user has never once seen them and therefore does not suspect they exist.

They come out through set-pdf-metadata with the clear-existing option turned on. Do it last or second to last: any operation after the cleanup will carry the now-empty fields forward, while replacing the file with a fresh export brings everything back.

Cropping hides, it does not delete

One more thing worth knowing before you send. Cropping a page changes only the visible area: a PDF stores two rectangles side by side, the physical sheet size and the visible part of it, and cropping edits the second.

The content beyond the boundary goes nowhere. It stays in the file, comes out by copying text, and returns to the screen when the crop is reset in any full editor.

For a document that has to lose personal data, cropping is the wrong tool entirely. What you need is redact-pdf with the black or white style: those genuinely erase the content under the rectangle. The blur style is not built for removal and says so in its own warning.

Take the password off in advance

A document protected by an open password will be refused by a form and by most document management systems: they cannot read the content in order to check it. That protection comes off through unlock-pdf, where you supply the password.

An owner password restricting printing and copying does not get in the way of processing, but some strict systems refuse it too: they need to extract the text, and a copy restriction formally forbids that. If a form refuses without a coherent reason and the file looks fine, that restriction is worth checking.

If nobody told you the requirements

Sometimes the form explains nothing and the help desk answers in a week. In that case take a set of values that is accepted almost everywhere rather than guessing.

One file instead of a package. A4 or Letter page format, identical on every sheet. Under ten megabytes: that is the threshold below which practically no form objects, and it is comfortable for email too. A text layer present. No password. Pages in the order they will be read, and none of them lying on its side.

A file like that gets through a bank, a university and a government portal alike. If a specific requirement turns out to be stricter, the refusal will tell you, and the fix will be a small one rather than a rebuild.

How to check the file before sending

Three checks, each taking seconds, each catching a different mistake.

Open the file in a program other than the one you made it in. A browser and a desktop viewer display rotated pages differently, because rotation is stored as a separate page property rather than as a rotation of the content. Better to see the discrepancy on your own screen.

Select a line of text with the mouse. That is the text-layer check, the same one the automation runs.

Open the document properties. The title and author are there, along with the page count and the weight. The page count is worth comparing with what you expect: a stray sheet from assembly gets noticed exactly here.

How to get the file ready

1. Assemble the whole document if it comes in parts. 2. Fix the pages: order, rotation, sheets that should not be there. 3. If it is a scan, recognise the text through ocr-pdf. 4. Clear the document properties if the file is going outside the company. 5. Compress with compress-pdf and confirm the weight fits the form's limit. 6. If it does not fit even after compression, split the document with split-pdf and send it in parts. 7. Open the finished file in another program and run the three checks above.