How to prepare a file for an online application
A practical AttachReady workflow: check upload requirements, choose an image or PDF tool, inspect the result, and download a file you can submit.
The form has three fields. You attach your ID scan, and it bounces back: "file cannot exceed 200KB". Your scan is 3.2 MB. Two fields are still empty and the session times out in twelve minutes.
That is the most common way an application stalls, and it says nothing about your materials being wrong. The file opened fine on your laptop. It just does not fit the portal's rules. Preparation is the work of finding out what those rules are, matching the file to them, and proving the match before you upload again.
Read the requirement off the form first
Do not compress first. Open the form and copy down every number and format it states. Most portals publish them in small grey text somewhere: allowed extensions, maximum bytes, pixel dimensions, page count, sometimes a cap on how many files one field accepts.
If a requirement is not stated, look for a help page or a downloadable instruction sheet. When nothing is published, prepare conservatively. A smaller file in a widely accepted format fails less often than a large one in an uncommon format.
Write the requirements down before you touch anything, and keep your originals untouched. Work on copies. A surprising number of submissions get stuck because someone overwrote their only clean scan with a compressed version and then found out the recipient wanted full resolution.
Match the failing requirement to a tool
Find the requirement you are failing, use the tool in the middle column, then verify the thing on the right.
| The form says | Open this | Then check |
|---|---|---|
| Photo must be under 200 KB | Compress an image | Actual byte count and whether small text is still legible |
| Must be exactly 600 × 800 pixels | Resize images or Crop images | Width, height and aspect ratio in the downloaded file |
| JPG only — mine is HEIC or PNG | Convert images | The real file type, not just the extension |
| Only one file allowed, I have four | Merge PDFs | Page count and the order of documents |
| Everything must be a single PDF | Images to PDF | Page order, orientation and total bytes |
| Scan is 8 MB and the limit is 1 MB | Compress a PDF | Whether body text survives at a readable size |
| The recipient wants pages 4–9 only | Select PDF pages | That the right pages came out, in the right order |
| I do not know what is actually wrong | File preflight | Each pass or fail check, with its measured value |
Two habits make this table usable. Change one thing at a time: converting PNG to JPEG fixes the format and does nothing about pixel dimensions. And re-read the requirements after every change, because portals usually impose several at once.
When the requirements fight each other
Requirements interact, and that is where people end up in loops.
Say the form wants JPEG, no more than 200,000 bytes, and at least 600 × 800 pixels. Those three are compatible. Now imagine a portal that wants 200,000 bytes and at least 2400 × 3200 pixels. At that resolution you are asking for a lot of detail in a very small file, and a scanned paper document may simply not survive the squeeze. No tool can make that pair work while keeping the text readable, and a service that promises otherwise is not being straight with you.
The practical order is format first, then dimensions, then bytes. Compressing before resizing throws away quality for nothing: you shrink a large image and then discard detail you just paid for. One more trap worth naming — 200 KB is not always 204,800 bytes. Portals that mean 200 KiB want the larger number, and the byte-limit details explain why that trips people up.
Understand where your file actually goes
Attachment files are often personal, so know which operations touch a server before you upload.
Browser-local operations run inside your browser tab. The file is decoded on your device and does not leave it. On AttachReady that covers the lightweight image inspections and the local JPEG compression option.
Server-side operations send the selected file to the processing service so a dedicated engine can do the work. Format conversion, PDF inspection, compression, merging, splitting and rotation all work this way, as do the higher-fidelity compression modes across the four output formats. Local checks and server conversions have genuinely different data paths, and file privacy and retention documents both.
Guest access covers a useful range without an account: up to three files, 5,000,000 bytes combined, 20 PDF pages and 12 megapixels per image, with a per-session attempt allowance. A free account raises the ceilings to ten inputs and 25,000,000 bytes and adds stored uploads, job history, saved rule templates, and REST or MCP access for scripted work. Higher tiers raise the counts, not the engine's safety limits.
Strict mode and best-effort mode are not the same promise
When you set a size target, you are also choosing how the service behaves if that target turns out to be unreachable.
Strict mode refuses to hand you the output. You get a report saying the target could not be met, with the measured facts. That is a useful answer — it tells you the requirement itself is the problem, and that you should talk to the recipient instead of grinding the file smaller.
Best-effort mode returns the smallest candidate it could verify, plus a warning that the target was missed. Use it when an over-limit file is still worth having, to see how close you got or to attach it somewhere with a looser rule. Use it knowingly: a file that downloads successfully is not automatically a file that passes.
Verify before you upload again
Open the result. Do not trust the summary alone.
Zoom to 100% on the smallest text in the document — an ID number, a date, a signature line. Detail loss shows up there first, long before it is visible anywhere else. Then compare the byte count against the limit exactly rather than eyeballing a rounded number, because 200 KB in one program is 204,800 bytes in another.
Check the page count, the order of documents, and the orientation of any page that started out landscape. Confirm the extension matches what the portal asked for. Then think about what processing removed. Compression and conversion typically strip location and camera metadata, which is usually what you want, but if the recipient expects an embedded timestamp, look at that before you submit.
Before you hit submit
Run through this quickly:
- Every stated requirement has a matching check you actually performed.
- The originals are still on your device, untouched.
- The output opens correctly in a normal reader or viewer.
- Guest outputs are already downloaded. They live in the page you were working in, so they are gone the moment you navigate away. Account artifacts expire after 24 hours, and the limits page lists the current ceilings.
Then upload. If it still fails, the error message is the most valuable thing you have, and the upload error guide walks through what each one means. Keep the expectation honest too: AttachReady verifies technical requirements. Whether the organization accepts your submission is their decision, and no tool makes it for you.
The first time through this takes twenty minutes. The second time takes three, because you will recognize the requirement types and stop guessing. If you would rather see the tools once before you need them, start with the quick tour.