Resume Upload Helper — Why a Job Portal Rejects Your File

What the diagnosis checks.

First, what the file really is: magic bytes reveal renamed files (a JPEG saved as .pdf still reads as a JPEG to the portal), ZIP containers masquerading as documents (.pages, renamed .zip), and legacy Word 97–2003 binaries that modern portals reject.

Then the security layer portals actually scan for: embedded JavaScript and automatic actions (the literal cause of “potentially unsafe content” rejections on SAP SuccessFactors), PDF portfolios and embedded attachments (explicitly refused by USAJobs), password protection and owner-password encryption, XFA forms, and digitally signed files. For DOCX, the package is checked for macros (VBA projects), tracked changes, layout tables, text boxes, and header/footer content.

Finally the parse reality: pages without a text layer (scans and photos), two-column geometry, embedded images, thin extractable text, and size against per-portal limits — including the “accepted but hollow” gap where a portal stores your file but its parser silently skips it (Greenhouse >2.5 MB, Ashby >16 MB, image files on Lever).

The error text is data.

Portal error strings are specific enough to diagnose from alone: “active contents” means scripts, “file type is not supported” can mean a dot inside your filename on SuccessFactors, “spins forever” is usually a session problem no file fix solves. Paste the exact wording — the matcher recognizes the phrasings portals really emit, and corroborated findings jump the ranking when your file confirms them.

Common questions.

What does “pdf contains potentially unsafe content” mean? The portal’s security scan found active content inside your PDF — usually embedded JavaScript, automatic actions, a PDF portfolio (files inside the file), or encryption. Some design tools and “interactive PDF” exports add these invisibly. The fix is almost always the same: open the file and Print → Save as PDF (or re-export from the source document) to strip the active layer.

Is this tool really free and private? Yes — free with no account, and private by construction: the file is inspected by JavaScript running in your browser. It is never uploaded to any server, so there is nothing to store, sell, or leak. The symptom text you paste is matched locally too.

My upload “works” but the fields come out empty — is that covered? Yes — that is a different failure class: the file attached but never parsed. We flag the causes (no text layer, two-column layout, tables, contact details in headers, or a file over the parser’s ceiling — Greenhouse attaches 100 MB files but only parses ~2.5 MB). For a full readability score, use the ATS checker.

What can this tool not diagnose? Portal-side incidents, expired sessions, browser extensions, and network failures leave no file signature — for those the tool gives you the evidence checklist instead. It also cannot verify employer-specific rules we have not documented; the verdicts reflect published limits and observed error strings.

What this checks, and what to check next.

The inspection covers the file itself. Employer-configured rules can differ from published defaults, and a portal-side outage leaves no trace in your file, so a clean diagnosis points to the environment instead (browser, session, network). The guide below walks that ladder.

For the full parse-quality score — what the fields will look like after upload — use the ATS checker’s parser preview.