PDF won't upload to the admission portal: fixes

A university application packet: assembling it so it gets accepted

An application to a university differs from an ordinary intake form in one way: there are many documents, each with its own requirements, and nothing can be fixed after the deadline. A rejection here costs more than in any other file-upload situation.

Let us treat assembling the packet as a task with a checkable result.

The packet is a list of requirements, not a folder of files

The first and most expensive mistake is putting everything into one PDF because "they asked for documents". There are usually several requirements, each with its own field in the form, and a glued-together packet is refused on completeness.

A useful rule to start from: the boundaries between files should follow the boundaries between documents on the requirements list. A degree certificate and its transcript are either one document or two, and that is decided by the wording of the requirement, not by your convenience.

The opposite mistake is just as common: a four-sheet transcript uploaded as four files, because the scanner produced them separately. That is exactly what merge-pdf is for: one document should arrive as one file.

If the requirement says "as a single file" and lists several documents, the order inside that file is usually specified too. Follow it literally: the committee reads the packet against the list.

Page limits and how to meet them

Many requirements carry a size ceiling: a motivation letter no longer than two pages, a portfolio of no more than twenty, a CV on one sheet.

Do not confuse two different limits here. A page limit has nothing to do with file weight, and compression does not solve it: a compressed document weighs less and holds exactly the same number of pages.

Surplus pages are removed by selection. extract-pages assembles a new file out of only the sheets you want, which is the right move when a large portfolio has to become a selection.

Check the result by the page counter in the document properties rather than by scrolling. A title sheet, a blank back and a contents page count like any other, and those are exactly what push a packet over the limit.

How to build the packet

1. Write out the list of requirements as a column: one requirement, one line. 2. Assemble each document into its own file, merging the pages of that one document. 3. Bring the length down to the stated ceiling by selecting pages. 4. Recognise scans through ocr-pdf if the admissions system searches across documents. 5. Clear the file properties. 6. Compress with compress-pdf last. 7. Walk the requirements list again, matching each line against a finished file.

Documents in different languages in one packet

An international application nearly always holds pairs: an original document and its translation.

How to submit them depends on the wording of the requirement. If there is one requirement and it speaks of a document with a translation, put them into one file in the order original, then translation. If there are two requirements, keep two files.

A certified translation should not be rebuilt at all. It is scanned whole, together with the translator's endorsement, the stamp and the binding, because those elements are what make it certified. Pulling "just the text" out of such a scan is not an option.

A separate note on recognising text in documents in other languages. English and Russian packs are available. Latin script is recognised by the English one, but diacritics are lost, so texts in French, German, Spanish or Portuguese will hold errors in the accents. For a document a human reads that does not matter; for a system matching a surname exactly, it can.

The deadline and which version went up

A category of trouble all its own, where the document is right and the wrong one was uploaded.

Application files live in a folder under names like "motivation_final", "motivation_final2", "motivation_final_ok". On the night before the deadline the wrong one gets picked, and the form makes that impossible to notice: it shows a file name, not the contents.

One simple action helps: after uploading, download the file back out of the form and open it. That is the only way to see with your own eyes what the system actually took. It costs a minute and removes a whole class of disasters.

The second deadline rule: do not compress the packet in the last hour. Compression changes the file, and there is no time left to check the result. Sort out the weight a day ahead, and spend the final day only uploading.

What the admissions office sees besides the content

Document properties travel with a file and are visible in any viewer. In student applications something unwanted turns up there regularly.

A document title left over from a template downloaded off somebody's website. An author name from the editor's settings, sometimes not yours if you did not make the file. An internal title along the lines of "letter for uni attempt 3".

None of those fields affects acceptance, but all of them are read by the committee. They come out through set-pdf-metadata with the clear-existing option on, and the right moment for it is just before the final compression.

The portfolio and its weight

A portfolio is the one part of the packet where weight usually becomes a problem: it is images, and there are many of them.

The order is the same as everywhere: first reach the required page count, then recognise if needed, and only then compress. Compression goes last because any processing after it inflates the file again.

If the portfolio still misses the weight limit after compression, pushing the quality down further is usually a mistake: the work stops being readable, and the work is what is being assessed. The sensible move is to shorten the selection, keeping fewer pieces at better quality.

File names a human will read

An intake form normally shows the committee the name the file was uploaded under. It is the one place in the packet where you speak to a person directly, and spending it on `scan_0043.pdf` is a waste.

A sensible scheme is surname, document type, language: `Ivanov_diploma_en.pdf`, `Ivanov_transcript_ru.pdf`. It reads without opening the file, sorts alphabetically into the right order, and contains nothing that could break when moving between systems.

What to avoid: spaces and non-Latin characters in names when the application is international. They are formally allowed, but some systems re-encode such names on export, and instead of a surname the committee sees a string of symbols. The rule is not strict, but following it is cheaper than explaining afterwards.

Dots inside the name are surplus too: `Ivanov.diploma.final.pdf` gets truncated at the first dot in some systems.

The check before sending

Three things, each under a minute.

The page counter in each file's properties against the ceiling in the requirements.

Opening each file in a browser rather than in the program you worked in: a browser's reader is closest to what admissions systems run, and it treats page rotation differently.

Matching the requirements list against the names of the uploaded files. Not against the contents of your folder, but against what the form shows after the upload.