Understanding FDA File Format Requirements: A Critical Step in Submission Readiness

When preparing regulatory submissions to the U.S. Food and Drug Administration (FDA), file format compliance is not just a technical detail; it’s a critical component to submission compliance. Submitting files in unsupported formats can lead to delays, data integrity issues, or even rejections. While the majority of content must be in PDF, sponsors often encounter challenges when incorporating non-PDF materials such as images, datasets, or proprietary outputs.

This blog explores the file formats accepted by the FDA, the common pitfalls of working with non-PDF documents, and best practices for ensuring your submission is compliant, efficient, and fully reviewable.

Always refer to the FDA’s allowable file formats guidance (https://www.fda.gov/media/85816/download) to confirm that your file type is permitted for the specific section of the submission and for the Center you're submitting to. Keep in mind that just because a format is allowed in one section doesn't mean it's allowed in others. Always double-check.

From Paper to PDF and Beyond: The Expanding Landscape of FDA-Accepted File Formats

Regulatory submissions have undergone a dramatic transformation over the past two decades. What once required reams of paper, binder clips, and courier shipments has shifted to structured electronic submissions driven by the electronic Common Technical Document (eCTD) format. At the heart of this evolution was the transition to PDFs as the standard for most submission content. This shift enabled consistent formatting, easier review, and electronic archiving.

However, as science and technology have advanced, so have the needs of reviewers and sponsors. Today’s regulatory dossiers may include high-resolution images, datasets, interactive models, or outputs from specialized software. This content is not always best represented or preserved in a static PDF format. In response, the FDA has begun accepting a broader range of file types under specific conditions to better reflect the complexity and nuance of modern product development.

This evolution ensures that the right data is presented in the right format to support efficient, high-quality review. The growing acceptance of non-PDF formats reflects the FDA’s recognition that modern submissions often require more flexible, fit-for-purpose documentation.

FDA-Accepted File Format Categories and Extensions

When submitting electronic content to the FDA, sponsors must adhere to strict guidelines on file formats.

Documents

Document formats like .pdf, .doc, .docx, are the backbone of FDA submissions. Protocols, study reports, and narratives are typically submitted as PDFs, the agency’s preferred format for its consistency and reviewability. Word files (.doc/.docx) are sometimes used during drafting and internal review, in certain sections only.

Images

Image formats such as .bmp, .gif, .jpg, .jpeg, and .png are used to convey visual data that can’t be easily captured in text—such as scanned case report forms, histology slides, annotated device photos, or chemical structure diagrams. These files support clarity in areas where visual context is essential. JPEG and PNG formats are most commonly used due to their balance of quality and file size, while BMPs may appear in legacy content. All images should be high-resolution and non-editable to preserve integrity and prevent accidental changes during submission preparation.

Audio/Video

Multimedia formats such as .mp4, .mp3, .wav, .wmv, and others are accepted when visual or auditory demonstration is necessary. The primary use for these files in eCTD structure is within Advertising and Promotional Submissions. However, there may be unique use cases where FDA may request videos, including device operation videos, surgical procedure clips, or audio files of patient-reported outcomes. For instance, an MP4 might be submitted to show how a wearable device collects data or to demonstrate usability in a pediatric population. MP4 is the preferred video format due to compatibility and compression efficiency. These files must be high quality, labeled, and directly relevant to the submission to justify their inclusion. If submitting a video file outside of the Advertising and Promotional section, you must ensure that you have explicit agreement from your Division Project Manager.

Coding Languages

File formats such as .xml, .xsd, .xsl, .css, .htm, and .html are used to define, structure, or present web-based and data-driven content in regulatory submissions. XML files are essential for backbone structures in eCTD submissions, defining metadata and enabling navigation within the dossier. XSD and XSL files often accompany XML to validate data structure and apply formatting. HTML files may be used to present dynamic content or create structured summaries with internal linking. CSS supports visual styling for these elements, though its use is limited. These files are rarely visible to reviewers but are critical for organizing, rendering, and validating the submission in FDA systems.

Data

Data file formats like .xpt, .csv, txt, xls, xlsx, .svg, and .zip are used to submit structured datasets and supporting metadata. The .xpt format, required for clinical study data (per FDA's Study Data Technical Conformance Guide), is typically used for SDTM and ADaM datasets in statistical submissions. Excel formats (.xls/.xlsx) are accepted for sortable data, such as safety listings, audit trails, or data validation outputs where reviewers need access to embedded formulas or filters. Text files (.txt) are the preferred format for executable program files. Sponsors may also include .csv files for supplemental tabular data, especially when sharing non-clinical or exploratory outputs. .svg is occasionally used to embed scalable graphics such as study flow diagrams or exposure-response plots.

ZIP files are currently only accepted for groups of aECG xml files, and by CDER Only. However, the FDA may accept ZIP files for other content types (high volume image sets, scripts, etc) on a case-by-case basis. Acceptability should be confirmed by consulting your Division Project Manager.

When submitting data in eCTD format, it is also crucial to note that beyond using permitted file types, the study data must also with the Study Data Technical Conformance Guide and meets format requirements based on the study start date and the receiving Center.

Modeling/Simulation: A Growing Presence in Regulatory Submissions

Modeling and simulation files—such as .sas, .r, .json, .dat, .cmp, .opd, .pkml, .mat, and others—are used to support model-informed drug development (MIDD) approaches. These formats capture pharmacokinetic/pharmacodynamic models, exposure-response analyses, and simulation outputs that inform dose selection or trial design. For example, a .r script might reproduce a population PK model, while .sas files can show derivation steps for a simulated dataset. Tools like NONMEM, Simcyp, and Monolix may generate proprietary outputs (e.g., .cmp or .pkml), which must be submitted in native form for FDA reviewers to verify reproducibility. If you’re submitting outputs from tools like NONMEM or Simcyp, flag them early. FDA often expects justification and clear documentation to validate these complex files.

Key Considerations When Using Non-PDF File Formats

While non-PDF formats can be necessary for specific data types or sponsor requirements, their use introduces operational complexities that must be managed. Importing these formats into publishing systems may require extensive manual intervention, particularly if the files originate from tools not natively supported by the software. This increases the risk of formatting errors and delays.

Non-PDF files, especially high-resolution images, videos, or large datasets, can also significantly inflate the size of a submission, resulting in longer transfer and validation times. Finally, unique or sponsor-driven file types may fall outside the FDA’s allowable format specifications, requiring negotiation with regulatory project managers or technical justification.

Best Practices for Managing Non-PDF Documents

Non-PDF files are sometimes unavoidable in FDA submissions, but their impact can be controlled through a combination of proactive planning and responsive mitigation. The following best practices help ensure non-PDF content is handled efficiently and compliantly.

Prevention: Avoiding Issues Before They Arise

Assess File Format Requirements Immediately As soon as a file is received, whether from a sponsor, CRO, or internal team, evaluate whether its format aligns with FDA-accepted specifications. This early assessment helps avoid scrambling during submission preparation.

Communicate File Format Expectations Early and Often Make sure all contributors understand which formats are acceptable and which require conversion. Provide file format guidelines to content providers and vendors up front to reduce the need for rework.

Delay Insertion into Early Builds If a file’s format is still under review or conversion, hold off on adding it to initial submission builds. This prevents downstream disruptions to hyperlinking, validation, or TOC generation.

Mitigation: Managing Risks When Prevention Isn’t Possible

Collaborate with Your Software Provider For proprietary or unusual file types, consult your publishing software vendor to determine if the files can be exported or converted into compliant formats without loss of fidelity.

Engage the RPM for Creative Solutions Regulatory Project Managers (RPMs) can provide guidance and flexibility for unique submission scenarios. For example, when dealing with a large number of image files, FDA allowed a single ZIP archive instead of separate uploads. This is a practical workaround that preserves content integrity while improving usability.

Conclusion

Navigating multiple file formats is essential to a compliant and efficient FDA submission. When sponsors understand not just what formats are accepted but also why and when to use them, they can avoid delays, protect data integrity, and streamline the review process. The key is early planning, clear communication with contributors, and aligning every file to its intended purpose.