PCB Data Formats: Gerber, ODB++ and IPC-2581

Choose PCB assembly manufacturing data formats by the information your assembler can verify, not by the file extension alone. Use a Gerber-based package when the receiving workflow reliably combines board data with an approved BOM, placement files and assembly instructions. Choose ODB++ or IPC-2581 when the exporter and recipient preserve the required manufacturing information. In every case, release one authoritative package, identify the controlling source for each data category, and require resolution of manufacturing-critical discrepancies before production preparation proceeds.

Choose the Handoff Around Required Manufacturing Information

A manufacturing handoff must tell the recipient what board to build, which parts to install, where they belong and which released configuration controls the work. Compare complete packages against those requirements. Comparing bare Gerber artwork with a fully populated intelligent product model gives a misleading result.

Start by separating information required for bare-board fabrication from information required for assembly, purchasing and test preparation. Then identify the receiving application and the team responsible for each category. A supplier’s ability to display copper layers does not establish its ability to extract a purchasing BOM or preserve component attributes.

The distinction is practical: The referenced supplier describes PCB production data, BOM data and component placement data as separate assembly inputs. That is one manufacturer’s documented workflow, not a requirement that every manufacturer must use identical files.

Compare coverage on the same basis

The matrix shows possible coverage, not proof that a particular export contains it. The format-specific sections explain the supporting specifications; the recipient checks are recommended acceptance actions.

Understand the cost of choosing badly

An unsuitable handoff creates work at the boundaries between systems. Purchasing may rebuild a parts list that engineering believed was embedded. Manufacturing engineering may recreate placements after receiving only board geometry. An old backup can become the accidental source for a new build.

Consider a hypothetical release in which the intelligent file imports correctly, but its manufacturer-part-number column is empty. A correct board image cannot resolve which qualified component to purchase. The project needs corrected field mapping or an explicitly controlling procurement BOM, not another screenshot of the board.

Evaluate the proposed handoff against avoidable clarification, reconstruction and reapproval effort. Ask what the recipient will consume directly and what it will create manually. There is no need to invent a universal cost premium or promise that one format always shortens lead time.

What Gerber Needs from Companion BOM and Placement Files

A Gerber-based assembly package normally needs an approved BOM and placement information alongside the board-manufacturing data. Keep those companions unless the recipient explicitly accepts equivalent information from the supplied Gerber component layers and verifies its completeness.

Distinguish Extended Gerber (RS-274X), Gerber X2 and Gerber X3. X2 adds attributes describing layer and feature meaning; X3 adds component information. An image may still display correctly when the receiving application ignores X2 attributes. Display compatibility is therefore not proof of information transfer.

Gerber X3 includes assembly-related component information. A qualified X3 workflow can use it instead of duplicating some placement or component records. Ordinary copper, mask and legend files are not an approved purchasing BOM merely because they have Gerber extensions.

For a conventional package, define the BOM’s purchasing responsibility separately from the CPL’s placement responsibility. Include reference designators, quantities and approved part identities in the purchasing information. Define X/Y units, origin, side and orientation conventions for placement. Provide board geometry and fabrication documentation in the recipient’s accepted arrangement.

The Gerber Job file can carry fabrication characteristics such as materials, finish and thickness, but it is not a complete assembly instruction set. Implementations may support only part of the available fields. Confirm which fields the recipient actually consumes.

Gerber Layer Format Specification Revision 2026.05 is the revision considered here. Record the exporter and enabled features; selecting ‘Gerber’ does not establish support for every feature in that revision. An established workflow may benefit more from improved attributes and release control than immediate format migration.

What ODB++ Can Carry and What Must Be Verified

ODB++ can carry an integrated manufacturing model, but the recipient must verify the actual model content. For this design-to-manufacturing handoff, specify ODB++Design; the wider ODB++ family also includes Process and Manufacturing formats with different roles, as the official ODB++Design site explains.

ODB++Design Release 8.1 Update 4, August 2024, defines a structured product model including layers, board profiles, component placements, EDA connectivity and BOM records. A compressed delivery contains that structure; compression does not prove all required records are present.

Ask the recipient to inspect the intended board step, component population and part-number relationships. A package can be sufficient for a fabricator yet insufficient for an assembler if assembly information was excluded. The ODB++Design datasheet explicitly describes sender control over included content, including exclusion of component-level information or changes to net names.

Check the boundary between the design model and purchasing. A CAD part identifier is not automatically the approved manufacturer part number. Specify whether procurement uses the embedded BOM or a separately controlled BOM, and require reconciliation of any duplicated identities.

For a new exporter/importer pairing, include examples that expose interpretation problems: an asymmetric connector, a polarized component and a bottom-side placement where the design contains them. Require confirmation against the released design intent, not simply confirmation that the archive opened.

Keep assembly instructions for information the receiving workflow does not extract. Choosing ODB++ does not authorize the assembler to infer mounting restrictions, test requirements or configuration decisions from geometry alone.

What IPC-2581 Can Carry and What Must Be Verified

IPC-2581 can carry structured fabrication and assembly information in XML, but support must be confirmed for the revision, exported content and receiving workflow. The IPC-2581 Consortium identifies the standard as IPC-DPMX, Digital Product Model Exchange.

Use a named revision in the handoff agreement. IPC’s Revision C release describes additions including rigid-flex information, embedded components and bidirectional design-for-manufacturing feedback. Those capabilities are not proof that an individual exporter populates them or that an assembler uses them. Legacy routes may involve Revision A or Revision B; retain them only where the agreed manufacturing requirements are preserved.

In the version 9.0 export example, IPC-2581B and IPC-2581C are selectable and BOM-field mapping is configurable. Manufacturer and manufacturer-part-number fields can be omitted. An apparently valid output can therefore lack the procurement identity needed for the order.

Confirm the intended content before export: fabrication geometry, stackup information relevant to the build, components, placements, connectivity and required part identities. After import, ask the recipient to show which of these became usable records in its working database.

Keep three approvals distinct. XML/schema validation addresses structural conformity. Import review addresses how the receiving application interpreted the data. Manufacturing acceptance addresses whether the resulting information is sufficient and correct for the job. Passing the first does not establish the other two.

Choose IPC-2581 when both parties can demonstrate that route for the required revision and content. When the accepted revision cannot express or transfer a required feature, select another qualified route or document an approved companion instruction. Do not silently downgrade the export and assume that the missing information is unimportant.

Check Import Support, Version Compatibility and Data Loss

Import support must be established for a specific application, version, enabled module and intended operation. “We accept IPC-2581” or “our viewer opens ODB++” is an initial answer, not a complete acceptance record.

The following examples distinguish software documentation from job-specific qualification. They do not establish which applications JASPER or another assembler operates.

An import plug-in’s documentation and a consortium support matrix describe capability at different levels. A product entry or historical version marker cannot replace a trial import in the actual receiving workflow.

Inspect both appearance and meaning. Compare layer roles, board dimensions, drill information, component identity, placements, connectivity and population intent. Then examine warnings, unsupported attributes and any manual edits made during conversion.

Rotation values deserve particular care. The Gerber Layer Format Specification defines positive component rotation as counterclockwise when viewed from top toward bottom; the ODB++ specification defines the CMP rotation field clockwise. Compare physical orientation in a common coordinate frame, not raw angle numbers. Account for bottom-side transformations and footprint zero orientation before deciding whether two placements disagree.

When an exporter setting, receiving application or translation plug-in changes, repeat the affected qualification checks. Preserve the previously approved package and its import evidence; a successful result with another software build does not prove the new route.

Apply Ten Evaluation Criteria Before Approving the Format

Evaluate each manufacturing-data route against observable evidence. Use the following criteria as an OEM review framework, not as a supplier ranking or a standard-mandated scoring system. A strong answer identifies the source, receiving record and owner; a weak answer relies on the format name.

Apply the criteria to the proposed transaction. A repeat order using a qualified Gerber package need not be migrated simply for novelty. A transfer to another assembler may justify a different format, but only after the receiving process demonstrates equivalent manufacturing meaning.

Do not turn missing evidence into an automatic rejection of the supplier. First distinguish an unsupported route from a correctable export setting or a missing controlled companion document. The practical decision is whether the resulting package can be made unambiguous before release.

Use a Six-Step Manufacturing Data Handoff Review

A manufacturing-data review should qualify the route before files become production inputs. Assign responsibilities explicitly so that a purchasing acknowledgment is not mistaken for engineering approval.

1. Define the required information

The OEM engineering owner identifies the board revision, assembly revision, configuration and manufacturing tasks covered by the handoff. Record which data categories must transfer digitally and which may be supplied as controlled documents. Keep requirements tied to the actual build.

2. Agree the receiving route

The assembler’s manufacturing engineer identifies the receiving software, supported revision, required modules and downstream outputs. Agree the primary format, companion files and trial-import evidence. Include the fabricator or test-engineering recipient where their separate workflows affect the decision.

3. Freeze and export the source

Generate the proposed package from the approved design state and selected assembly configuration. Record export settings, populated BOM mappings and coordinate assumptions. When generating a second format, use the same released source rather than a later working copy.

4. Perform the recipient trial import

The recipient imports the package into the intended workflow and returns recognized layers, component references, required fields and warnings. Reconcile the complete required object sets: equal component counts can hide a missing reference replaced by an unintended duplicate. Use selected asymmetric and bottom-side views to check transformations, not as a substitute for that reconciliation. Define comparison precision separately from physical placement tolerances; exported decimal precision is not an assembly-machine capability claim.

5. Resolve exceptions and approve meaning

The OEM and recipient reconcile missing fields, unexplained object differences and instruction conflicts. Document whether each issue requires a corrected export, a qualified alternative format or an approved companion instruction. Recheck affected data after corrections rather than approving the earlier import report.

6. Release and acknowledge the package

The OEM releases the final manifest and controlled files. The recipient acknowledges the release identity, controlling sources and disposition of exceptions. Archive that evidence with the order. Reopen the review when a later change affects the approved route or manufacturing meaning.

Release One Authoritative Package with a Readable Backup

An authoritative release package can contain several file types without creating several competing masters. Define authority by information category: geometry, procurement, placements and assembly instructions do not have to be controlled by the same physical file.

Include readable top/bottom assembly views, the released parts list and instructions needed for review. Mark whether each document controls a requirement or merely visualizes data controlled elsewhere. A drawing may control a mounting instruction while its component view remains reference-only. Assign that authority by requirement; do not use a broad “PDF takes precedence” rule to bypass a model conflict.

The following example assigns separate authorities within one conventional Gerber release. Its board revision and assembly revision identify different controlled objects; the release identity binds them to one approved build.

For ODB++ or IPC-2581, the manifest can assign geometry and placement authority to the intelligent model while retaining a separately controlled purchasing BOM or instruction document. State that division explicitly and reconcile duplicated data before release.

Use a manifest with file names, revisions and checksums to detect accidental substitution or corruption. A checksum establishes file identity, not engineering correctness or approval. Preserve the export configuration and acceptance record with the archive.

Do not send Gerber, ODB++ and IPC-2581 as three equally authoritative alternatives. An alternate representation may be useful for review or recovery, but identify its status and require a controlled decision before it replaces the accepted production source.

Escalate These Eight Handoff Signals

Escalate a handoff when required manufacturing meaning is missing, ambiguous or dependent on an unqualified translation. Hold the affected preparation until the responsible owner resolves the issue; change format only when that addresses the underlying problem.

1. The archive opens, but required components, placements or purchasing identities are absent. Request corrected content or an agreed companion source.
2. The selected revision is unsupported by the receiving application. Agree a compatible export and recheck any changed representation.
3. Required attributes disappear during conversion. Identify the lost meaning and qualify its replacement before proceeding.
4. Bottom-side or asymmetric parts import with unexplained orientation changes. Resolve the coordinate transformation against design intent.
5. Board-step or panel interpretation is uncertain. Establish the intended manufacturing unit and coordinate frame.
6. The model and controlling assembly documents describe different builds. Return the conflict to OEM engineering rather than choosing locally.
7. The recipient cannot provide object-level evidence for information needed downstream. Qualify a different tool or a supported data route.
8. Multiple packages claim production authority without a release manifest. Withdraw ambiguity and reissue one coordinated release.

Frequently Asked Questions

These answers address the format-selection decision. Use the agreed release arrangement and recipient import evidence to determine which particular files your project needs.

Prepare the Next Handoff with JASPER

Prepare the board and assembly revision identifiers, intended build configuration, proposed manufacturing format, approved purchasing information and readable assembly instructions. Include the export application/version and ask for confirmation of the receiving route and required companion files before finalizing the package.

For a project using JASPER PCB assembly services, make the acceptance question specific: can this package preserve the information needed for this build, and which source controls each requirement? Select Gerber, ODB++ or IPC-2581 on that evidence, then release one coordinated package for the agreed work.