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?”
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.
| Rule | Regular PDF | PDF/A |
|---|---|---|
| Fonts | Can reference a font by name and hope the viewer has it | Must be embedded — every font travels inside the file |
| Encryption | Passwords allowed | Prohibited entirely |
| External references | Allowed | None — everything must be self-contained |
| JavaScript, audio, video | Allowed | Not allowed |
| Color profile | Depends on the viewer | Defined and embedded |
The font rule is the one people run into most: a regular PDF that only names its font is why text sometimes shows as boxes years later on a different machine — PDF/A doesn’t allow that gamble. The no-encryption rule follows the same logic from a different angle: an archive that requires a password to open is a liability the moment that password is lost, so you cannot lock a PDF/A file and still have it validate as PDF/A. The result across every row 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.
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.
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 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.
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.