Both open the same way, look the same on screen, and use the same file extension — but “PDF” and “PDF/A” answer different questions. A regular PDF asks “does this look right today, on the software available today?” PDF/A asks “will this still open correctly in 50 years, on software nobody has written yet?”
What PDF/A actually restricts
PDF/A is an ISO-standardized subset of PDF, built for long-term archiving, and it works by forbidding things a regular PDF is allowed to do:
- Fonts must be embedded. A regular PDF can reference a font by name and hope the viewer has it (which is part of why text sometimes shows as boxes years later on a different machine). PDF/A doesn’t allow that gamble — every font used has to travel inside the file.
- No encryption or passwords. An archive that requires a password to open is a liability the moment that password is lost, so PDF/A prohibits it entirely — you cannot lock a PDF/A file and still have it validate as PDF/A.
- No external references. Nothing in the document can depend on a link, a file, or content living outside the PDF itself — everything needed to render it correctly has to be self-contained.
- No JavaScript or executable content, and no audio/video, since decades-old software has no guarantee of being able to run either safely.
- A defined, embedded color profile, so colors render consistently regardless of what’s rendering them, rather than depending on the viewing device’s own color handling.
The result is a file that’s deliberately less capable than a normal PDF, in exchange for being far more certain to render identically on whatever opens it next, whenever that is.
Who actually requires it
PDF/A shows up as a hard requirement in a specific set of contexts: court and legal filings, patent applications, government and regulatory archives, medical records systems, and corporate long-term record retention — anywhere a document needs to be provably readable on a specific future date without depending on any particular software still existing. If a submission portal specifically says “PDF/A required” rather than just “PDF,” it usually means the file will be validated against these rules, and a regular PDF with, say, a non-embedded font will be rejected.
What this means for a normal PDF
For the overwhelming majority of everyday PDFs — invoices, reports, CVs, contracts sent between people who’ll open them within the next few years — PDF/A’s guarantees solve a problem you don’t have. Ordinary PDF export from Word, Excel, or PowerPoint already embeds fonts by default, which covers the most common real-world failure (fonts breaking on another machine) without needing full PDF/A compliance.
Where the PDF/A rules intersect with things this site’s tools already do: converting with Word to PDF or Excel to PDF embeds fonts as standard, and checking a file’s properties with PDF Metadata covers the same document-properties transparency PDF/A cares about. What none of our tools do is validate or certify strict, full PDF/A conformance — if a portal specifically demands a PDF/A-validated file, that requires dedicated archival software built to check every rule above, not just produce a well-formed regular PDF.
Ready? If your PDF just needs to open reliably everywhere — not pass formal PDF/A validation — Word to PDF and Excel to PDF already embed fonts by default, free and with no sign-up.