Drop in a file and its structure is examined locally: does it start and end the way its format requires?
Most file corruption shows up structurally: a truncated download loses the format's closing marker, a bad copy flips the opening signature, a dying drive returns zeros. This checker reads the file's first and last bytes and, per format, verifies the landmarks that must be present, a PDF's header and end-of-file marker, a ZIP's end-of-central-directory record, a PNG's IEND chunk, a JPEG's end-of-image marker, a WebP's declared size against its real size, and reports each landmark found or missing, plus signs of zero-filled regions.
Be clear about the limit: structural checks prove a file is complete and well-formed at the container level; they cannot prove the content inside is undamaged (a PDF can be structurally whole with a garbled page inside, and only opening it fully shows that). A 'damaged' verdict here is strong evidence of corruption; a 'healthy' verdict means the container is intact, pair it with opening the file in its real application for certainty. Nothing is uploaded: the bytes are read in the browser.
My file opens fine but the checker complains, who is right? Possibly both: some writers produce slightly non-standard files (missing a final marker, unusual padding) that readers tolerate. The report names the exact landmark missing so the judgement can be weighed.
Can this repair the file? No, it diagnoses. For PDFs and ZIPs, the recovery tools on this site (PDF Recovery, ZIP Recovery) attempt best-effort extraction from damaged files.
Why does it ask for the whole file if it only checks the ends? Browsers read files as a whole through the file picker; the checker also scans for large zero-filled regions, which requires the middle as well.