3 min readGuides
A PDF/A label matters only when the finished file passes validation
Understand what PDF/A is, how archival conversion changes a document, and why preparation, validation, and human inspection are separate steps.
The short answer
PDF/A is a preservation-focused family of PDF standards that limits fragile dependencies and requires a conforming file to carry the information needed for reliable future rendering. Conversion is not complete until the chosen profile is validated and the result is visually and functionally checked.
- PDF/A is a conformance target for preservation, not a filename, extension, or visual style.
- Preparing interactive content and creating a clean PDF can reduce conversion surprises but do not certify PDF/A compliance.
- A sound archival workflow validates the requested profile and then checks appearance, searchability, metadata, and page completeness.
PDF/A is a preservation-oriented form of PDF designed to reduce dependencies that may make a document difficult to reproduce later. It is not a different filename extension, and it is not established by how the pages look in an ordinary viewer. A file becomes a credible archival deliverable only when it conforms to the PDF/A profile requested by the archive, records system, regulator, or recipient.
That distinction changes the workflow. “Save as PDF” creates a PDF. “Prepare, convert, validate, and inspect” creates evidence that a particular output meets an archival requirement. For a broader discussion of when the extra effort is justified, see when you need a PDF/A archival file. This guide concentrates on the handoff between source preparation and acceptance.
What PDF/A changes about conversion
A normal PDF can depend on features that are awkward preservation bets: resources that are not fully contained in the file, interactive behavior, encryption, or document structures that a future system may not interpret as expected. PDF/A profiles constrain which PDF features may be used and how they must be represented.
Conversion software may therefore need to embed resources, rewrite metadata, remove unsupported behavior, or turn interactive appearances into fixed page content. Those changes can affect more than compliance:
- form fields may stop being editable;
- links, annotations, scripts, or media may be removed or altered;
- font substitution can change line breaks or symbols;
- rasterization can preserve the visible page while sacrificing searchable text;
- rewritten metadata may no longer match the source record.
This is why “the file opens” is an insufficient test. It proves that one reader can display something, not that the output conforms to the required archival profile or preserved every important property.
Prepare the document without pretending to certify it
Start by asking the receiving authority for the exact PDF/A part and conformance level it accepts. Do not choose a target merely because it sounds newer or stricter. The required profile determines which features must be retained, transformed, or removed.
If you are producing a straightforward source document, the browser-based PDF creation tool can create a new searchable PDF with structured text, links, tables, images, page settings, headers, and footers. It is useful for producing a clean ordinary PDF before an archival conversion step. It does not emit or certify PDF/A.
If the source contains completed form fields or annotations that should become fixed appearances, the PDF flattening tool with explicit output modes can prepare a separate copy. Its Standard mode retains native searchable text while locking supported widgets and annotations into page content. Raster modes replace pages with images and can remove searchability, links, forms, and accessibility information. Some modes also remove supported metadata values.
Flattening is therefore a trade-off, not a universal archival fix. It can simplify interactive content, but it does not by itself embed every required font, write the required conformance metadata, or validate a PDF/A profile. Keep the original source and choose a mode only after deciding which properties the archive needs.
Validate first, then perform a human check
After specialist conversion, run a validator that supports the requested PDF/A profile. Treat warnings and failures as specific defects to investigate, not as boxes to dismiss. If the receiving authority supplies its own validator or submission portal, that result should govern the handoff.
Then inspect the accepted file as a reader:
- Confirm the page count, dimensions, and orientation.
- Compare the first, middle, and last pages with the source.
- Check small symbols, accented characters, formulas, and custom fonts.
- Search for several known phrases and copy a paragraph into plain text.
- Inspect title, author, dates, and other metadata required by the records process.
- Test links, tags, or reading order only when the selected profile and use case are meant to preserve them.
- Record the validator, profile, date, result, and exact file that passed.
The final point prevents a common process failure: validating one copy and later submitting a re-saved copy. If the archival file changes after validation, validate it again.
The creation and flattening workflows described here process selected document content in the browser. Runtime assets may still load from the application origin, so browser-local processing should not be confused with a promise of no network requests.
Sources and further viewing
Tools used in this guide
Each workspace runs in this browser tab. Open one directly to apply the steps above to your own document.
Written by The PdfEditorOnlineFree team. Published . Product behaviour described here reflects the linked workspaces at the time of review; check the tool page for current limits.