← All guides · Part of the court requirements series
Florida is the furthest along of any state on PDF/A mandates. The requirements below come from the Florida Courts' own PDF/A Frequently Asked Questions published through MyFLCourtAccess (the e-filing portal for Florida's courts) — check the portal for the current version before relying on this page.
The preferred format for submission is PDF/A-2a (or current equivalent). For scanned documents — where the filer cannot create a born-digital file — PDF/A-2b is the acceptable subtype, and 2b documents can be made searchable with OCR. The distinction the FAQ draws: 2a retains "document intelligence" (searchable, screen-reader friendly), while 2b preserves the rendered appearance with minimal compliance. The portal currently still accepts Word and ordinary PDF filings and converts them to PDF/A itself, and it checks each document and displays an error if it is not PDF/A — described as informational at the time the FAQ was written, with a phase-in that clerks extended (the FAQ cites extensions to June 30, 2022).
| Permitted document-intelligence elements | Prohibited (not passed to the clerk) |
|---|---|
| Bookmarks · electronic signatures (s/, signature image, signature pad — Rule 2.515) · attachments created by the Insert feature · internal links · embedded persistent external hyperlinks · embedded images | Digital signatures and digital notarizations requiring an encryption key · embedded attachments · comments and annotations · hidden deleted items (must be purged) · non-persistent external hyperlinks · embedded thumbnails · form fields and actions · JavaScript · embedded non-display data |
Encryption is prohibited. A compliant PDF/A file "must be open and available to anyone or any software that processes the file" — user IDs and passwords may not be embedded. Born-digital documents must use US Letter (8.5″ × 11″) page size and fonts per the Rules of Judicial Administration.
The FAQ's longest section is about fonts that appear from nowhere: the PDF has unembedded fonts, yet the Word original contains no trace of them. The culprit it names is Word silently substituting — the documented example is Times New Roman becoming TimesNewRomanPSMT, one of the "common system fonts" Word omits when "Do not embed common system fonts" is checked. The fix sequence in the FAQ: File → Options → Save → check Embed fonts in the file, and uncheck both "Embed only the characters used" and "Do not embed common system fonts". The 14 fonts exempt from embedding under the base PDF spec (Times/Helvetica/Courier families, Symbol, ZapfDingbats) are listed as the safe set.
Two more warnings worth heeding: Word 2016's PDF/A export "jumbles" words per the FAQ (their advice was to submit the Word file or a plain PDF and let the portal convert), and a font may be copyrighted such that it cannot be embedded — the creator should warn you, and it is more common with some non-Western fonts.
The FAQ's own words: scanned files "are a disaster from the beginning" — a scan is a snapshot and "can never be made a PDF/A"; if forced through conversion it "will rarely pass the conformity test", because PDF/A is a self-contained file and a scan lacks the underlying data. Practically: OCR the scan, save as PDF/A-2b, and verify — the FAQ's verification method is Acrobat's Standards panel → "Verify Conformance", expecting "verification succeeded".
The portal requires metadata to be scrubbed, yet the FAQ notes a file whose metadata was fully scrubbed fails Acrobat's conformity verification — because conformance checking itself relies on metadata such as the producer field. The FAQ's proposed reconciliation: remove any metadata not required for compliance, keep what the PDF/A standard requires. If your filing is rejected on metadata, check whether the scrub removed conformance-required fields.