BLOG
PDF/A is a family of PDF standards intended for long-term preservation. If an archive or customer specifically requests it, confirm the exact PDF/A variant, convert a copy, validate compliance, and inspect the document itself. Renaming a file or choosing an export preset is not proof that it meets the required standard. Adobe’s Acrobat Pro guidance describes conversion profiles and Preflight validation.
Confirm the delivery requirement
Ask which PDF/A level or profile the receiving organization accepts, whether it needs searchable text, and whether it also requires a digital signature or specific metadata. “Send a PDF” and “send PDF/A” are different instructions. If the receiver provides a validation tool or portal, use its criteria as part of the final test. Do not assume that one PDF/A variant will satisfy every archive process.
Start with a readable, complete source
Preserve the original PDF and check all pages before conversion. Make sure images, fonts, links, tables, and page order are correct. If the file is a scan, decide whether OCR is required for searchability; PDF/A compliance by itself does not guarantee that a person can select or search the text. Fix missing pages or unreadable scans at the source where possible. Conversion should not become a way to hide a document problem.
Convert a copy in Acrobat Pro
- Open the correct source PDF in a supported Acrobat Pro version.
- Use the current PDF standards or Preflight tools documented by Adobe.
- Select the PDF/A profile required by the recipient, such as a specific PDF/A-1b profile when that is the stated requirement.
- Analyze and fix issues, then save under a new filename.
- Run the relevant compliance validation on the saved file.
- Open the saved copy and inspect pages, text, images, and other required features.
- Submit that exact validated file to the destination and retain the source.
Adobe’s interface can change; refer to the current help and profile names in your version. Some conversions may fail or require a source fix. A failed Preflight result is a reason to investigate, not to relabel an ordinary PDF as compliant.
| Check | Why it matters |
|---|---|
| Requested profile | Different receivers may require different PDF/A variants |
| Validator result | Confirms technical compliance, not just an extension |
| Visual content | Pages, images, and fonts must still convey the information |
| Searchability | A scan may need OCR if the workflow expects text search |
Understand what long-term preservation means
The purpose of PDF/A is to make a document more self-contained and suitable for future rendering under defined rules. That does not mean every viewer will show every interactive feature unchanged. Consider whether the document depends on external content, a form action, an embedded file, or media. If those features are essential, ask the archive how they should be preserved. Do not assume that converting to PDF/A is a substitute for keeping original source records.
Validate content after technical compliance
A validator checks rules in the file; it cannot tell whether the proposal has the correct customer name or whether page three is missing. Reopen the saved document and compare it with the source. Inspect symbols, special characters, small text, color, and page breaks. If a font is substituted or an image changes, correct the source or conversion settings and validate again. The final record needs both technical and editorial accuracy.
Handle scans separately
A scanned PDF can be converted to a PDF/A-compliant file, but the page may remain an image. If the archive expects searchable content, run OCR and verify names, amounts, and reading order. A recognized text layer can contain mistakes while the visual page looks correct. Keep the original scan for comparison and identify which version was delivered. A file that passes format validation is not automatically an accurate transcription.
Plan the signature sequence
If a file is already digitally signed, changing it may invalidate that signature or alter the verification result. Confirm the recipient’s required workflow before converting a signed original. When possible, prepare and validate the archival version before the signing stage, then check the signed artifact according to the receiver’s rules. Do not infer signature validity from a visible signature graphic on the page.
Keep evidence of what was sent
Save the source, converted copy, profile or tool used, validation result, and delivery record in the appropriate project folder. Use filenames that distinguish draft, validated, and signed versions. A receiving portal may reject a technically valid file for another reason, such as an unsupported variant or excessive size, so keep the actual submission response as well. This makes later correction possible without guessing which version was sent.
Common questions
Is changing .pdf to .pdfa enough? No. Compliance is determined by the file’s structure and validation result.
Can I convert a scanned PDF? Often yes, but scan quality and any required searchable text need separate attention.
Does a passing validator mean the document is correct? It supports technical compliance, not completeness or factual accuracy.
Confirm the requested profile, convert a separate copy, validate it, and compare the content with the original. The destination’s requirement and the actual saved file are the final tests.
For a batch export, run validation on each final file or on a documented automated process that reports failures by filename. Do not infer that the whole batch passed because one sample did. Keep failed documents outside the approved delivery folder until a person checks the cause and reruns conversion. This prevents a mixed archive of compliant and ordinary PDFs under the same label.
Imagine an archive asks for PDF/A-2b and the employee selects the first PDF/A preset they see. The file may pass a validator for a different profile yet fail the archive’s upload rule. Write the exact requested variant in the project checklist. Save the validation report with the same filename as the delivered document so the team can connect evidence to the actual upload rather than a previous draft.
A readable PDF/A should be checked in more than one place: the local viewer, the validator, and the receiving portal when one exists. A portal rejection may concern size, security settings, or missing metadata rather than page appearance. Read the error and correct the source or conversion method. Do not repeatedly upload renamed copies without understanding the reason for failure.
If documents are produced regularly, standardize the source template and export process before archiving hundreds of files. Embedded fonts, stable page size, and accurate metadata are easier to manage at creation than to repair in every derivative. Sample the process on a typical document and a difficult one with tables or scans. Keep the human content check even when technical validation is automated.
For long-term records, think about the organizational context as well as the file standard. Record the document title, date, version, owner, and relationship to other files so a future colleague knows which artifact is authoritative. PDF/A can improve preservation of a file’s display, but it does not create a retention policy or explain why the record matters. Put the validated copy in the correct archive location with appropriate access and backup rather than leaving it in a personal downloads folder.
