Pre-processing for an archive
Generate a candidate file with the basic PDF/A-1b identification before it goes into an electronic records system, then check it with the institution's validator.
Guide
PDF to PDF/A produces a copy carrying a basic PDF/A-1b archival identification. The tool first checks whether the font resources of the original PDF are embedded; if they pass, it rebuilds the document in the workspace's current page arrangement, writes pdfaid:part=1 and conformance=B XMP metadata plus an sRGB OutputIntent, sets the PDF version header to 1.4 and turns object streams off.
Updated 2026-09-274 min read
PDF to PDF/A produces a copy carrying a basic PDF/A-1b archival identification. The tool first checks whether the font resources of the original PDF are embedded; if they pass, it rebuilds the document in the workspace's current page arrangement, writes pdfaid:part=1 and conformance=B XMP metadata plus an sRGB OutputIntent, sets the PDF version header to 1.4 and turns object streams off.
When unembedded fonts are found, the interface requires “whole-page rasterisation” before it will continue: pages are rebuilt at a fixed 150 DPI with JPEG quality 0.9, and the text layer goes with them. This is explicitly a best-effort basic conversion — it does not fix transparency, complex colour spaces or every other PDF/A rule — so run the result through veraPDF or another validator before submitting it to an archive.
<original-name>_PDFA.pdf and check it with veraPDF or whatever validator the receiving organisation specifies; if the ICC fetch failed, the interface warns that no embedded colour profile was written this time.| Input | Output | Notes |
|---|---|---|
the font check reports all 6 fonts embedded |
the page content structure is kept while the document is rebuilt, then PDF/A-1b XMP and an sRGB OutputIntent are written |
strict compliance still needs external validation |
2 unembedded fonts detected |
conversion is refused until rasterisation is on; with it on, the whole document is rebuilt as image pages at 150 DPI and the archival identification is written |
the text layer is lost |
the browser cannot fetch the sRGB ICC from the CDN |
the file is still generated with an OutputIntent declaration, alongside an "ICC fetch failed" warning |
all the more reason to re-check with a validator |
Generate a candidate file with the basic PDF/A-1b identification before it goes into an electronic records system, then check it with the institution's validator.
Identify unembedded fonts before converting and decide whether the loss of the text layer from 150 DPI rasterisation is acceptable.
Rearrange or rotate pages in the PDF workspace first, then produce the PDF/A candidate from the current arrangement.
No. The tool covers one set of basic requirements, and the code explicitly does not handle deeper rules such as transparency or complex colour spaces; use veraPDF or the recipient's validator for the final verdict.
The current implementation does not go looking for missing fonts and embed them; rasterisation freezes the page appearance into an image, sidestepping the font dependency at the cost of the text layer and interactive content.
No. The PDF itself is always processed locally in the browser; only when the cache lacks the sRGB ICC profile does the browser request that small colour profile from the jsDelivr CDN.
PDF content is always checked, rebuilt and exported locally in the browser and is never uploaded; on the first run or a cache miss the browser requests the sRGB ICC colour profile from the jsDelivr CDN and writes it into the browser Cache API for later use.
Updated 2026-09-27
Basic conversion: writes the PDF/A-1b identifier and sRGB OutputIntent and checks font embedding; strict compliance is not guaranteed, verify with a validator
Everything runs locally in your browser; files are never uploaded to a server