E-filing preflight: a checklist before you file

Updated September 5, 2026. Requirements vary by court and change without notice. Every item below must be confirmed against your court's current guidance. Not legal advice.

Why filings bounce

Court filing systems check the technical shape of a document more than its content. A filing can be rejected, or accepted and then struck, because the file is too large, is a scan with no searchable text, contains form fields or comments, embeds another file, has no bookmarks when the local rule requires them for long documents, or exposes a Social Security number that Rule 5.2 says must be redacted. Each of these is easy to check and easy to miss at 11 p.m. on the day of the deadline.

Federal courts and CM-ECF

Federal courts file through CM-ECF. The system accepts PDF, and district-level guidance typically adds requirements such as:

• A per-file size limit, which varies by district and is revised periodically. Large filings are split into volumes below the limit, with exhibits attached as separate documents.
• Text-searchable PDFs. Scanned documents need an OCR text layer.
• No embedded files, scripts or active content. Attachments inside a PDF, JavaScript and multimedia are commonly prohibited.
• Flattened forms and no comments. Form fields should be flattened to static content and review annotations removed.
• Fonts embedded. So the document renders identically on the court's systems.
• Bookmarks for lengthy documents and for exhibits, required by some districts and by many judges' standing orders.
• PDF/A, required or preferred in some districts for archival reasons.
• Redaction of the personal identifiers listed in Rule 5.2, which is the filer's responsibility.

State courts

State e-filing runs on a mix of vendor platforms and court-built systems, each with its own file-size limits, format rules and redaction requirements. Some states require PDF/A; some require specific page sizes; many have their own list of protected personal identifiers that is longer than the federal one. The court's e-filing manual and the local rules are the sources; the vendor's help pages are useful for technical limits.

The preflight checklist

• File is a PDF and opens without errors in a second viewer.
• File size is under the court's current limit, or the filing is split into volumes that are.
• Every page is text-searchable; scanned pages have been through OCR.
• No embedded files, no JavaScript, no multimedia.
• Form fields flattened; no comments, highlights or sticky notes remain.
• All fonts embedded.
• Page size matches the court's requirement, usually Letter in US courts.
• Bookmarks present for long documents and for each exhibit, with titles that match the index.
• PDF/A conversion applied and validated if the court requires it.
• Rule 5.2 identifiers and any protected-order material redacted with true redaction and verified.
• Document metadata cleared of anything you would not want the other side to read.
• Bates numbers and exhibit labels present where the filing needs them.

How ExhibitSet handles it

ExhibitSet's preflight runs the checklist above against a court profile before export, reports pass or fail per item, shows the rules and their sources with the report, and fixes what can be fixed safely with one click: stripping scripts and attachments, flattening forms, removing comments, splitting into labelled parts at a size cap. Profiles are data, not code, so a firm can edit any rule to match a local requirement, and every limit that varies by court is flagged for you to confirm rather than silently assumed. ExhibitSet checks for common PDF/A problems, names what blocks conformance when something does, and writes the PDF/A identifier and output intent when nothing in the pages does. It never claims a file conforms, and it will not write the declaration onto a file that would fail without it; validate with your court's tool if PDF/A is required. In early access today.