PDF/A, and Keeping a Document Readable in 2050

Run a regular PDF past a PDF/A validator and it usually fails for one of three reasons: a font that isn't embedded, a link or script reaching outside the file, or encryption. We converted a Word document and a Markdown file through FileFlip's own routes and checked the output against those same three rules with pdffonts and pdfinfo. It passed all three, and it still isn't a valid PDF/A file, for a reason that's the most useful thing in this article.

When do you actually need PDF/A?

Make a PDF/A file when:

• the document has to open correctly in twenty or fifty years, and you won't be the one opening it
• a court, agency or archive named "PDF/A" specifically, not just "PDF"
• you're the one filing something for permanent retention, not sending a file to a colleague this afternoon

A regular PDF is fine when:

• a person opens it this week, not a system decades from now
• the document needs live links, a fillable form, or an embedded video
• Convert DOCX to PDF or Convert Markdown to PDF already gives you a file with every font embedded and nothing pointing outside it, which covers most of what people mean when they say "archival PDF" without needing the PDF/A label at all

PDF/A at a glance

Does FileFlip's own PDF qualify as PDF/A?

Mostly, and then not at all, depending on which part of the definition you check.

We took a one-page Markdown file with a heading, a bulleted list and a hyperlink, ran it through Markdown to PDF, and did the same for the equivalent DOCX through DOCX to PDF. Both routes go through the same Pandoc-to-HTML-to-MuPDF pipeline, and both produced the identical 121,703-byte file. pdffonts showed both text styles, Nimbus Roman Regular and Bold, embedded rather than referenced.

pdfinfo reported no JavaScript and no encryption. Searching the raw bytes for /URI, /Launch and /EmbeddedFile found nothing, not even the hyperlink from the source Markdown: the word "link" survived, the https://example.com it pointed to did not.

The first four rows are the plain-English description of PDF/A that most people repeat, and our output clears every one of them. The last two are what a validator like veraPDF actually checks first, and neither is there. A PDF that merely avoids the banned features is not the same file as one carrying the XMP block and colour profile that name it as PDF/A, and only dedicated PDF/A software writes that block.

Method and exact commands are at the bottom of this page.

What does PDF/A actually forbid, and why?

PDF/A is ISO 19005, a standard that takes ordinary PDF and removes anything whose meaning could depend on something outside the file. JavaScript is out, because a script's behaviour depends on a PDF viewer's implementation, which changes across decades. Encryption is out, because a password or a proprietary rights-management scheme can make a file permanently unreadable the moment the software that enforced it disappears, which is the opposite of what an archive wants. Every font has to be embedded, and embeddable under its own licence, so text doesn't silently reflow into Times New Roman on a machine that lacks whatever font the document was written in. Colour has to be declared in a device-independent space with an ICC profile attached, so "this red" means the same thing on a screen built in 2005 and one built in 2050.

The standard has grown in parts. PDF/A-1 (2005) is built on PDF 1.4, so it has no concept of transparency, layers or JPEG 2000, features PDF didn't have yet. PDF/A-2 (2011) moved to PDF 1.7 and added support for all three, plus the ability to nest a compliant PDF/A file inside another. PDF/A-3 (2012) is identical to Part 2 except it allows embedding any file format at all, which is what lets an invoice PDF/A carry its own source spreadsheet. PDF/A-4 (2020) is rebuilt on PDF 2.0, the same ISO 32000-2 specification our own PDF format reference cites for plain PDF. Each part also has "a" and "b" conformance levels, and Part 2 adds "u": level a requires the document be tagged for accessibility, level b only requires that it render identically, and level u adds a requirement that the text map to real Unicode characters so it stays searchable and copyable.

Who actually requires PDF/A?

Courts and archives, though "requires" is doing less work than it sounds like. The Eastern District of Oklahoma's own PDF/A FAQ explains that federal courts want the format "to reduce security risks and to improve the ability to archive," and adds plainly that filers are "encouraged" to switch, with no deadline set. That's the state of most US federal courts right now: PDF/A is preferred, occasionally required by a specific court's local rule, but not yet mandatory system-wide.

Government archives are the other main audience. The US National Archives accepts PDF as a transfer format for permanent records, and PDF/A specifically is the version built to survive the transfer.

What matters more than the PDF/A label?

Whether the format is structured text at all, according to the people who actually run an archive.

The Library of Congress ranks the formats it accepts for long-term preservation into two tiers, Preferred and Acceptable, and publishes the list every year in its Recommended Formats Statement. For textual works, the Preferred tier is XHTML, XML-based formats including DOCX and ODF, and SGML, with a single "page-layout" entry: plain, web-optimized PDF. PDF/A doesn't appear until the Acceptable tier, sitting alongside PDF/UA and a "highest quality" PDF profile, one rung below the structured-text formats.

The reasoning follows from what PDF/A actually is: a page-layout format that fixes text at a coordinate, encoded reliably, rather than a format that says what the text means. A validator can confirm a PDF/A file's fonts are embedded. It can't confirm that "Section 2" is a heading rather than large bold text, because PDF has no such concept to check.

What formats outlive a page-layout PDF?

Plain text and structured markup, for the same reason a PDF/A label doesn't help: a file that's just characters, or characters plus a widely documented schema, needs no viewer to reconstruct it, only a text editor. Markdown, covered on the Markdown format reference, is deliberately built to be readable unprocessed: strip every asterisk and hash and a Markdown file still reads as text. DOCX is a ZIP of XML parts under an ECMA and ISO standard (ECMA-376 / ISO/IEC 29500), which is exactly the property that puts it in the Library of Congress's Preferred tier alongside PDF/A's own format family.

Encryption is the clearest example of the same tension: it's a real capability of ordinary PDF and DOCX, useful the day you set it and useless, or worse, unreadable, the day nobody remembers the password. That's the plainest case for what a conversion actually costs you: every format buys a capability by giving something else up, and PDF/A's whole design is giving up encryption, scripts and external links so nothing about the file can go stale except the bytes it was never going to lose anyway.

Common questions

Can I open a PDF/A file in a normal PDF reader?

Yes. PDF/A is still PDF, so Preview, Adobe Acrobat Reader, and every browser's built-in viewer opens it exactly like any other PDF. Only PDF/A-specific software checks whether it actually conforms to the standard; an ordinary reader has no idea and doesn't care.

Does converting a scanned document to PDF/A make the text searchable?

No. PDF/A controls the container, not what's inside it. A scanned page is a picture of a page whether it's wrapped in ordinary PDF or PDF/A, and needs a separate OCR pass to turn those pixels into selectable text either way.

Can a PDF/A file be password protected?

No, in every part of the standard. Encryption is banned outright, because a password or rights-management scheme tied to today's software can leave the file permanently locked once that software is gone, which defeats the entire point of an archival format.

Does Microsoft Word or Adobe Acrobat export directly to PDF/A?

Acrobat Pro does, through its Preflight or "Save as Other" tools. Word's own Save As PDF does not add the required metadata on its own. LibreOffice does it more directly: its own PDF export documentation describes converting straight to PDF/A-1b or PDF/A-2b from the export dialog, embedding every font used in the source document as part of the same step.

Convert between them

FileFlip converts DOCX and Markdown to PDF entirely in your browser, on WebAssembly builds of Pandoc and MuPDF. Nothing is uploaded: the file is read off your disk, converted on your own machine, and saved back by the browser, which is also why nothing about the file ever leaves the tab you're using. Open the DOCX to PDF or Markdown to PDF converter, drop your file on it, and the fonts come out embedded with nothing in the result pointing outside itself, as measured above.

Turning that into a validator-passing PDF/A still needs dedicated PDF/A software to add the XMP and colour-profile metadata; FileFlip doesn't write that block today.

The PDF format reference, DOCX format reference and Markdown format reference cover each format's own capabilities in full.

How we measured this

• Source files: a one-page Markdown file (a heading, bold text, a hyperlink, a bulleted list, a closing paragraph) and the same content converted to DOCX with Pandoc, so both inputs describe an identical document.
• Conversion: run through FileFlip itself at localhost:3000/convert-md-to-pdf and /convert-docx-to-pdf in a real browser session, downloading the resulting PDF from each.
• Font check: pdffonts output.pdf, from Poppler, which reports whether each font used in the file is embedded, subsetted, and what encoding it uses.
• Structure check: pdfinfo output.pdf for JavaScript, encryption, tagging and metadata-stream presence; a raw byte search of the file for /URI, /Launch, /EmbeddedFile, /Metadata and /OutputIntent to check for external references and the marker XMP would leave behind.
• Tools: Poppler's pdffonts and pdfinfo (Homebrew build), Python 3 for the byte search, on macOS.
• Caveat: this is a single one-page text document with no images or forms. A DOCX with a scanned image, a tracked-change comment thread, or an embedded video would test different parts of the PDF/A ban list than this one did.