PDF to PDF/A Converter Online: An Honest India Guide

PDF/A conversion in your browser is impossible. We do not try. We built a free pre-flight checker that tells you exactly what would prevent your PDF from being PDF/A-compliant — so you can fix it locally with Ghostscript or Acrobat Pro before submitting to the MCA21 portal, the GSTN attachment slot, or a High Court e-filing system. Search results for "pdf to pdf/a converter online" return dozens of tools that claim to convert in the browser. Most ship output that fails veraPDF, the canonical ISO 19005 validator. For Indian regulatory filings, that is a trust-killing failure mode we refuse to ship.

This guide is the honest version of the search query. Section 1 explains why browser-only PDF/A conversion does not work. Section 2 explains when PDF/A actually matters in India — MCA21 annual returns, GSTN attachments, court e-filing — with citations. Section 3 walks through what ISO 19005-1b conformance level B requires, ten clauses at a time. Sections 4 through 6 cover the pre-flight checker, the real conversion tools (Ghostscript, Acrobat Pro, LibreOffice), and the end-to-end workflow.

Why this is a checker, not a converter

A real PDF/A-1b converter has to do four things that pdf-lib — the JavaScript PDF library that runs in the browser — cannot do well. The four are:

1. Embed a complete ICC color profile. ISO 19005-1 §6.2.3 requires that any document using DeviceRGB, DeviceCMYK, or DeviceGray declare an OutputIntent dictionary pointing at an embedded ICC profile (typically sRGB IEC61966-2.1, a binary blob of about 3 KB). pdf-lib has no built-in API to embed an ICC stream as a /DestOutputProfile reference. Writing the dictionary by hand is possible but the resulting structure rarely passes validation on the first try.
2. Subset every font. §6.3.4 mandates that every font referenced in the document have its program embedded in the PDF. PDF/A-1 also requires fonts be subset where possible to avoid licensing complications. pdf-lib can embed a font you supply, but it cannot extract a font already referenced in an existing PDF, subset it to the glyphs used, and re-embed the subset. That is a font-engineering problem solved by HarfBuzz and FreeType — not a pdf-lib feature, and not a browser-only feature any time soon.
3. Write a valid XMP packet with the pdfaid namespace. §6.7 mandates an XMP metadata stream in the document catalog. §6.7.11 mandates the packet include the pdfaid namespace (xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/") declaring the conformance part and level. pdf-lib has no XMP authoring API — you would write the XML by hand, including the rdf:Description machinery, byte order marks, and the trailing whitespace padding the spec recommends. Possible, but error-prone in a way that breaks validators.
4. Flatten transparency without rasterising. §6.4 forbids transparency. If the source PDF uses transparency (modern Office exports often do), every transparent region needs to be flattened — split into opaque regions that approximate the visual result. Done correctly, this is what Adobe calls the Flattener Library; done badly, the document becomes a giant rasterised image that loses text searchability and fails PDF/A-1a tagged-content compliance. pdf-lib cannot flatten transparency at all.

Browser-based competitors that claim to convert to PDF/A typically skip all four problems and just set a metadata flag. The output renders fine in Adobe Reader. The marketing copy is satisfied. The file fails veraPDF. The regulator portal rejects it. The CS or CA who used the tool blames the portal, not the tool, because the tool said it converted successfully.

For a mass-market consumer audience, that gap might not matter. For an India regulatory audience filing annual returns, GST refunds, or court submissions, it matters a lot. The cost of a failed validation is concrete: a missed deadline, a paid extension, or a paper-print fallback at 11 PM. We built the /pdf-to-pdfa-precheck tool as a checker rather than a converter because the honest path is to tell you exactly what would fail before you waste another upload attempt.

MCA21, GSTN, and court e-filing — when PDF/A actually matters

Three regulatory contexts in India routinely demand PDF/A-conformant output. Each has its own validation behaviour and its own cost of rejection.

Ministry of Corporate Affairs (MCA21)

The MCA21 portal accepts annual returns (Form AOC-4, Form MGT-7), board resolutions attached to e-forms, and director KYC submissions (Form DIR-3 KYC). Several form types require PDF/A and the upload screen rejects non-conformant files with a generic "file not in PDF/A format" error. The MCA general circulars on e-filing reference ISO 19005 directly. The attachment validator runs at upload time, so you find out immediately — but a CS preparing an annual return on the day of the deadline does not have time for two or three rounds of re-conversion. Searching for "pdf to pdf/a converter online" near 5 PM on the last day is the most common reason this guide gets read.

GST Network (gst.gov.in)

GSTN attachment slots — refund claim supporting documents, advance ruling applications, notice replies, audit replies — sometimes require PDF/A archival format. The portal validation is less strict than MCA21 but still rejects encrypted PDFs, files containing JavaScript or embedded multimedia, and files larger than 5 MB. For invoice attachments under refund claims, the file format requirement is documented in the GST Refund Manual; non-conformant uploads stall the application. The common failure mode is encryption — Indian banks ship statements password-protected, and CAs sometimes attach the encrypted file directly. Run such files through /unlock-pdf first to remove the password before any PDF/A pre-check.

High Court and e-Courts e-filing

The e-Courts project and several individual High Court e-filing portals (Delhi HC, Bombay HC, Karnataka HC, Madras HC) accept case documents in PDF/A. The Delhi HC e-filing rules document explicitly references PDF/A-1b. Validation rules vary by court — some portals run veraPDF server-side, others do a lighter check. For a missed-deadline matter, a non-conformant PDF rejection is the reason a litigant pays a printer to certify a paper copy at midnight. For ongoing matters, a CS or advocate preparing affidavits, plaints, and replies routinely sees PDF/A as the required format.

For all three contexts, the cost of a failed validation is concrete and time-sensitive. That is the audience this guide is written for. The pre-check tells you the truth in 5 to 15 seconds, in your browser, without ever uploading the file.

What ISO 19005-1b actually requires

ISO 19005-1:2005 defines PDF/A-1, the original archival profile of PDF. It has two conformance levels: A (accessible — adds structure tagging requirements) and B (basic — visual fidelity only). For Indian regulatory submissions, level B is the common target because the structural-tagging requirements of level A are harder to meet on documents originally authored in Word, LaTeX, or accounting software without explicit tag output.

The ten-point summary of conformance level B:

1. No encryption. §6.1.3 forbids the /Encrypt dictionary. Password-protected PDFs are out by definition.
2. No JavaScript, URI, or Launch actions. §6.6.1 and §6.6.2 forbid these action types in any annotation, the catalog OpenAction, or any name tree. PDF/A is for archival; executable content is the opposite of archival.
3. No embedded files or attachments. §6.9 forbids /EmbeddedFiles, /Filespec, and FileAttachment annotations. The PDF must be self-contained.
4. No transparency. §6.4 forbids /SMask soft masks and any /CA or /ca alpha value less than 1.0 in any extended graphics state. This is the hardest clause to fix automatically because flattening transparency well is a non-trivial graphics problem.
5. XMP metadata stream required. §6.7 mandates a /Metadata reference in the document catalog pointing at an XMP packet.
6. PDF/A identifier in XMP. §6.7.11 mandates pdfaid:part and pdfaid:conformance elements in the XMP packet, declaring the conformance part (1, 2, or 3) and level (A, B, or U).
7. All fonts embedded and subset. §6.3.4 requires every font program be embedded in the PDF. Type3 fonts must have charprocs. Composite fonts must have their CIDFont program embedded.
8. OutputIntent with embedded ICC profile. §6.2.3 and §6.2.4 require an /OutputIntents array with at least one entry whose /DestOutputProfile points at an embedded ICC profile stream.
9. No multimedia annotations. §6.5.3 forbids Movie, Sound, and 3D annotation subtypes.
10. AcroForm fields must have appearance streams. §6.9 requires that interactive form fields have their appearance streams baked in. The /NeedAppearances flag must be either absent or false. Form fields without appearance streams may render differently in different viewers, which violates the visual-fidelity guarantee.

The full standard is ISO 19005-1:2005 (purchase required). The PDF Association maintains a free primer at pdfa.org that covers the practical implications of each clause without the ISO membership barrier.

What the pre-flight checker does

The /pdf-to-pdfa-precheck tool runs the ten checks above against your PDF, in your browser, and reports PASS, WARN, or FAIL per check with the exact remediation tool for each failure. The implementation uses a hybrid approach: pdf-lib parses the catalog and page tree for structural inspection, while raw byte-stream regex scanning catches objects and annotations that pdf-lib does not expose directly. Total runtime is 5 to 15 seconds depending on the document size.

Each FAIL row in the output expands to show what we found and the exact tool to fix it. Examples:

• FAIL on encryption → /unlock-pdf to remove the password locally, then re-run the pre-check.
• FAIL on AcroForm appearances → /flatten-pdf to bake form fields into the page content stream. After flattening, the form is no longer interactive but the visual layout is preserved and PDF/A clauses pass.
• FAIL on missing OutputIntent or ICC profile → use Ghostscript with the PDF/A flag to add a sRGB OutputIntent. The exact command is in the next section.
• FAIL on transparency or font embedding → these are not fixable by single-tool tweaks. The honest answer is to re-export the source from Word, LaTeX, or LibreOffice with PDF/A enabled, or run the existing PDF through Ghostscript or Acrobat Pro.
• FAIL on embedded files or JavaScript → use /redact-pdf workflow to remove the offending objects, or re-export from the source if the embedded content is part of the original document layout.

The checker also exports a JSON report with each finding, byte offset, and recommended fix — useful for CI gates that run on generated PDFs, or for compliance evidence packages where the pre-check output is part of the audit trail.

Tools that actually produce valid PDF/A-1b

If the pre-check shows FAIL on your file, three tools produce veraPDF-clean output today. None is browser-only.

1. Ghostscript (free, open source)

One command, runs locally, no upload:

gs -dPDFA=1 -dPDFACompatibilityPolicy=1 \
   -sColorConversionStrategy=RGB \
   -sOutputICCProfile=sRGB.icc \
   -sDEVICE=pdfwrite \
   -o output.pdf input.pdf

sRGB.icc ships with most Ghostscript installs in the iccprofiles/ directory. On macOS install with brew install ghostscript. On Ubuntu use apt install ghostscript. On Windows download from ghostscript.com/releases. The output passes veraPDF on most office documents — the failure modes are usually edge cases with non-Latin scripts (font character encoding completeness) or content streams inside Form XObjects.

2. Adobe Acrobat Pro (paid, ~USD 14.99/month)

File → Save As Other → PDF/A. Acrobat Pro is the most reliable conversion path because the same vendor wrote the original PDF specification and the reference implementation. The internal handling of ICC profiles, font subsetting, XMP authoring, and transparency flattening is the most complete in the market. The subscription cost is meaningful for individual filers; for CS firms and CA practices it is usually already in the budget.

3. LibreOffice (free, open source)

File → Export As → Export As PDF → General tab → check PDF/A-1a. Works only when the source document is editable in LibreOffice (.docx, .odt, .xlsx, .pptx). The output is generally clean but has occasional font-embedding gaps for less common scripts — run the pre-check on the result before submitting. For documents that originated in Word or Google Docs, exporting to PDF/A directly from the source application is usually cleaner than exporting to PDF and converting after.

The full workflow: precheck → fix → re-precheck → submit

For a CS preparing an annual return at 4 PM with a 5 PM deadline, the practical workflow is:

1. Run the pre-check first. Drop the assembled PDF into /pdf-to-pdfa-precheck. In 5 to 15 seconds you get a per-clause PASS / WARN / FAIL report. If everything is PASS, skip to step 4.
2. Fix each FAIL with the recommended tool. Encryption → unlock-pdf. AcroForm appearances → flatten-pdf. Missing OutputIntent → run the Ghostscript command above. Transparency → re-export from source with PDF/A enabled, or run through Acrobat Pro / Ghostscript. Each fix is local, with no upload.
3. Re-run the pre-check. Confirm every clause now reports PASS. WARN findings are usually safe to submit but worth flagging in your filing notes if the document is large or unusual.
4. Validate with veraPDF before the deadline. For high-stakes filings, the final gate is veraPDF itself. Download from verapdf.org/software, run java -jar verapdf-greenfield-X.Y.Z.jar --format text yourfile.pdf. If both the pre-check and veraPDF pass, the regulator portal will accept the file.
5. Submit. Upload to MCA21, GSTN, or the relevant e-filing portal. Keep the JSON pre-check report and the veraPDF output in your records — useful evidence if the file is challenged later or if there is a dispute about upload time.