currently supports three ECAD file formats, although we're planning to add support for more in future. Some ECAD systems may be able to produce files in one or more of the supported formats, so this page explains a little more about these formats and the advantages and disadvantages of each.

You can check if your ECAD system produces these file formats by looking at our Supported Systems page.

IDF 2.0 & 3.0

File Suffixes: *.emn/*emp, *.brd/*.pro, *.brd/*.lib, *.bdf/*.ldf


IDF (Intermediate Data Format) is the best known ECAD-MCAD interchange file format. IDF was developed in the early 1990's by a company called Intermedius Design Integration, LLC. The idea was to create a simple text-based file format for the interchange of data between Electrical and Mechanical CAD systems and vice-versa.

Unlike the other file formats supported by, IDF was specifically designed with ECAD-MCAD interchange in mind. As a result, the data in the file format is very easy for Mechanical CAD systems to use to build simple 3D models. Shapes of entities like components and keep-out areas can only be defined as a single closed profile. This makes IDF a very robust format for data-exchange, but drastically limits the level of detail that can be exchanged. IDF only supports the basic board shape, component holes, mechanical holes, basic component and keep-out shapes. It does not support more complex entity types such as copper areas, routing/traces, vias, silkscreen etc. IDF also doesn't support the concept of layers - the outputting CAD system simply provides an overall board height.

There are three versions of the IDF file format; IDF 2.0, IDF 3.0 and IDF 4.0. As far as we're aware, IDF 1.0 was never officially released.

IDF 2.0 and 3.0 are both very similar simple text-based formats. IDF 3.0 files are virtually identical to IDF 2.0 files, but add support for more keep-out, keep-in and outline types. IDF 2.0 and 3.0 are by far the most common versions of the IDF file format, and most ECAD systems will be able to generate one or both versions. can read both IDF 2.0 and IDF 3.0 files.

IDF 4.0 was released in 1998 and was designed to address a lot of the shortcomings of the earlier formats. It marked a radical change from IDF 3.0, adopting an XML-like file structure and supporting many new entity types and ways of defining much more complex shapes. Unfortunately this increase in the complexity of the format also meant it wasn't as rapidly or widely adopted as the earlier versions. As IDF 4.0 was a complete redesign rather than an evolution of IDF 3.0, few ECAD or MCAD vendors wrote translators for it, and the format is now not in widespread use. can't currently read IDF 4.0 files.

Recognising an IDF 2.0 or 3.0 file:

The major source of confusion with IDF 2.0 and 3.0 files is that each 'IDF file' is represented by two files on disk. The first file, commonly known as the Board File contains the information needed to model the board, along with its holes, keep-in and keep-out areas etc. This file also defines the position of the components; however, it doesn't describe the shape of the components. The component shapes are defined in a second file (usually called the Library File). Most ECAD systems provide both parts of the file, usually with the same name but different suffixes - for example 'pcbtest.emn' and 'pcbtest.emp'.

To add to the confusion further, the file suffixes used by ECAD systems for their IDF 2.0 and 3.0 Board and Library files varies by system. The most commonly used suffixes are *.emn for the Board File, and *.emp for the Library file, but other suffix combinations are used including *.brd/*.pro, *.brd/*.lib, and *.bdf/*.ldf. Where possible we've put the file suffixes to expect from your ECAD system on our Supported Systems page.

Whatever file suffixes are used for IDF 2.0 and 3.0 files, their contents are always the same, so you can convert a *.brd/*.pro IDF file pair into a *.emn/*.emp IDF file pair for example, simply by renaming the files. will read all the IDF 2.0 and 3.0 file suffixes in common use. If you upload just the 'Board' part of the IDF file, will only show a model of the board. To show the board and components you'll need to upload both the Board and Library parts of the IDF file, one after the other.

IDF files are written in plain text and humanly-readable, so an easy way to check if you have an IDF file is to open it with a text editor like Notepad. If you have an IDF 2.0 or 3.0 file the first few lines should look something like this:

BOARD_FILE 2.0 "OrCAD Layout" 1999/8/3.14:47:07 1
"example1" THOU

The first text on the second line should be 'BOARD_FILE' for the Board section of the file or 'LIBRARY_FILE' for the Library section of the file. The next item om the second line should read '2.0' for an IDF 2.0 file or '3.0' to indicate an IDF 3.0 file.


IDF is the ideal format to use if you want to create a simple MCAD model to check space constraints or for basic thermal analysis. The lack of support for copper and silkscreen entities makes it less suitable for generating realistic board models for sales and marketing uses.

  • Widespread Support: The majority of ECAD systems can generate IDF 2.0 or 3.0 files.
  • Low File Size: The file format is quite compact as it only contains a subset of the ECAD data.
  • Lack of detail: Only describes the basic board, component and keep-in/keep-out shapes. No support for copper areas, routing/tracing, vias, silkscreen etc.
  • Which file(s) to use can be confusing: Two separate files are needed to build a complete model. File suffixes aren't standard across ECAD systems.
  • No longer developed: There is no ongoing development to produce new versions of the format with support for additional features.

IPC 2581A

File Suffixes: *.cvg, *.xml


IPC-2581 is an open, neutrally maintained XML-based global standard for PCB design data transfer. Unlike IDF, IPC-2581 is actively developed by a large and active group of PCB design and supply chain companies including major ECAD vendors like Cadence and Zuken.

IPC-2581 wasn't designed as a format for ECAD-MCAD interchange - it's designed as a format for board designers to transfer board design, fabrication and test information to manufacturers, replacing older formats like Gerber.

However, if a file contains enough information to manufacture a physical board, then it also contains enough to manufacture a digital model of the same board, hence's support for the format.

Because IPC-2581 files can contain all the information needed to manufacture a board, it means can extract the trace/route and silkscreen areas from these files to produce much more detailed models than it can using IDF files.

However, due to the additional complexity in IPC-2581 data over simpler formats like IDF, the resulting more-complex MCAD models generates could get very large. If this becomes a problem in your MCAD system consider using the filtering tools built into or a simpler format like IDF.

Recognising an IPC-2581 file:

IPC-2581 files usually use the *.cvg file suffix, although *.xml is sometimes also used (the format is XML-based). As the IPC-2581 Consortium is an active group, an up to date list of products that support the format is listed on the Consortium's Website.


  • Excellent Detail: IPC-2581 files contain all the information needed to build very detailed board models including copper and silkscreen layers.
  • Developing format: IPC-2581 is backed by a large number of successful ECAD and MCAD companies and should continue to develop in future to keep up with new technologies in board design.
  • Not yet widely supported
  • IPC-2581 files can get very large: As IPC-2581 files can contain data describing every entity on the board and the format is XML-based, the files can get very large for more complex boards. Larger files will take longer to upload to and process.
  • Could create large MCAD models: As there's much more complexity in IPC-2581 data than in simpler formats like IDF the more complex MCAD models generated from it could get very large.

Autodesk Eagle Board File (v6.0 onwards)

File Suffix: *.brd


If you use the popular Eagle ECAD system and you're using version 6.0 or later, then can read this system's native *.brd format.

As *.brd is Eagle's native format, the files contain all the information needs to produce very detailed models. However, as Eagle is a 2D system, some entities (such as components) may not have a height defined and may come through to with a zero or nominal height.

Eagle version 7.0 and later can also save to the IDF file format, also supported by IDF only contains basic board shape data so it may be more suited for applications not needing board detail such as producing simple 3D models for analysis.

Recognising an Eagle Board File:

Eagle Board Files have a *.brd suffix, although please note that the *.brd suffix is also used by some other ECAD systems for an IDF 2.0 or 3.0 Board File.

Eagle's format is XML-based from version 6.0 onwards. If you open an Eagle 6.0 or later *.brd file with a text editor such as Notepad then the first few lines should be similar to this:

<?xml version="1.0" encoding="utf-8"?>
<eagle version="6.1">


  • Excellent Detail: As *.brd is Eagle's native format, the files contain all the information needed to build very detailed board models including copper and silkscreen layers.
  • ECAD system specific: Files can only be written by Autodesk Eagle v6.0 and later.
  • Little 3D data: Eagle is a 2D system, so some height data required for 3D models may be missing from the files.
  • Could create large MCAD models: As there's much more complexity in Eagle data than in simpler formats like IDF, the more complex MCAD models generated from it could get very large.