Altium file formats, and what each becomes in KiCad.
Altium Designer writes several file types, and each has a different KiCad counterpart and a different migration story. This page names each file, shows what is inside the binary container Crosspad reads in the browser, and states the scope a migration order supports — quoted from the terms, not paraphrased.
Six file types, four KiCad counterparts.
The extension tells you what the file holds; the container tells you how it can be read; the KiCad counterpart tells you what a migration has to produce.
| FILE | WHAT IT IS | CONTAINER | KICAD COUNTERPART | CROSSPAD PAGE |
|---|---|---|---|---|
.PcbDoc | PCB document — the board: layers, tracks, arcs, pads, vias, fills. | Binary OLE2 compound file (Altium Designer 6 and later). | .kicad_pcb | PcbDoc → KiCad |
.SchDoc | Schematic document — one schematic sheet. | Binary OLE2 compound file. | .kicad_sch | SchDoc → KiCad |
.PcbLib | Footprint library. | Binary library file; KiCad reads it directly since 8.0.0. | .pretty footprint library | Altium libraries → KiCad |
.SchLib | Symbol library. | Binary library file; KiCad reads it directly since 8.0.0. | .kicad_sym | Altium libraries → KiCad |
.IntLib | Integrated library — symbols and footprints packaged together. | Binary library file; KiCad reads it directly since 8.0.0. | .kicad_sym + .pretty | Altium libraries → KiCad |
.PrjPcb | Project file — which documents belong together. | Text project file; KiCad imports a whole project since 9.0.3. | .kicad_pro | Altium → KiCad migration |
ASCII .PcbDoc | A board written as ASCII text instead of the compound-binary container. | ASCII |KEY=VALUE| text, opening with |RECORD=Board. | .kicad_pcb (converted to the binary form and reconciled first) | Why it imports as an empty board |
Pre-V6 (Protel) .PcbDoc | Older boards written in the pre-V6 binary layout. | Not the modern compound-binary container. | — (unsupported; re-save from a current Altium Designer) | Why it imports as an empty board |
KiCad version facts (library import since 8.0.0, project import since 9.0.3) are sourced on the importer reference page. The “container” column describes what Crosspad's in-browser reader recognises. Source: State of the KiCad Altium importer.
A small filesystem in a file.
A modern .PcbDoc is an OLE2 compound file (the MS-CFB format): a container of named storages and streams, identified by the eight-byte signature D0 CF 11 E0 A1 B1 1A E1. Each board object class lives in its own storage with a Data stream. Crosspad's in-browser viewer reads that container directly — the file is parsed locally and nothing is uploaded.
| STREAM | CONTENT | HOW IT IS READ |
|---|---|---|
Board6/Data | Board parameters: the layer stack (LAYER<n>NAME) and the origin. | ASCII |KEY=VALUE| parameter blob. |
Nets6/Data | Net records — the names copper belongs to. | ASCII |KEY=VALUE| records. |
Components6/Data | Component placements and their designators. | ASCII |KEY=VALUE| records. |
Tracks6/Data | Line segments (tracks). | Binary records: [u8 type][u32 length][body]. |
Arcs6/Data | Arc records. | Binary records. |
Vias6/Data | Via records. | Binary records. |
Pads6/Data | Pad records. | Binary records. |
Fills6/Data | Rectangular fill records. | Binary records. |
Polygons6/Data | Copper pours (polygon fills). | ASCII |KEY=VALUE| records. |
Regions6/Data | Filled regions and cutouts. | Binary records. |
Texts6/Data | Text strings placed on the board. | Binary records. |
WideStrings6/Data | Unicode text for the strings above. | Binary index: [u32 index][u32 length][UTF-16LE]. |
Coordinates are stored as 32-bit integers in units of 1/10000 mil; Crosspad converts them to millimetres for display.
The streams above are what the in-browser viewer renders. A migration order validates the full set of domains listed below, which the viewer does not attempt.
What an Order commits us to, at launch.
Quoted from Section 3 of the Commercial Beta Terms and Scope — the commitments that govern your Order. Anything not listed is Unsupported; the analysis returns Blocked, or the report marks the item UNSUPPORTED.
| ITEM | SUPPORTED AT LAUNCH |
|---|---|
| Source file type | Altium Designer .PcbDoc (PCB document), in either form Altium writes: the binary (compound-file) form, or the ASCII text form — which we convert to the binary form and reconcile against an independent count of your board before migrating it. A .zip archive is accepted as a container for one such board: we read the single .PcbDoc inside it, or — where the archive holds several boards together with a single .PrjPcb that names exactly one of them — the board that project file itself names. An archive widens what you may send us; it does not widen what we migrate, which is one board. .SchDoc, .PrjPcb and libraries are not in scope at launch, sent on their own or carried inside an archive. |
| File size | Up to 10 MB per file. For a .zip, that is the size of the archive as you send it, not of its expanded contents. Larger files: contact us before ordering. |
| Altium version | Files written by Altium Designer version 6 or later. Pre-Version-6 (Protel) binaries are not in scope. |
| Target | KiCad 10.0.5 (.kicad_pro and .kicad_pcb). |
| Boards per Order | One Source File per single-project Order; multi-project tiers as listed in the Order. |
| Language of reports | English. |
Through the browser today
The 10 MB above is what the Terms allow. The uploader accepts up to 4 MB, because a larger upload is refused by the hosting platform before it reaches us — so the file picker turns a bigger board away instead of failing halfway. If your board is over 4 MB, write to us and we will run it for you.
Unsupported at launch
The following are outside the Supported Scope. The Analysis will return Blocked, or the report will mark the item UNSUPPORTED. They are not Material Defects and are not covered by Remediation.
An ASCII-format .PcbDoc whose conversion cannot be reconciled. We convert the ASCII text form and check the conversion against an independent count of the board; where the two disagree we do not migrate it — the Analysis returns Blocked or the report marks the file UNSUPPORTED, and nothing is charged.
Files from Altium versions earlier than version 6 (pre-V6 binary format).
Schematic documents (.SchDoc), project files (.PrjPcb) and libraries (.SchLib, .PcbLib) — on their own, and equally inside an accepted archive, where they are ignored rather than migrated. They are not converted, not validated under Section 4, and appear in no evidence category of Section 5 except UNSUPPORTED. Sending a project inside a .zip gets the board in it migrated; it does not get the project migrated.
An archive holding more than one board that no .PrjPcb inside it resolves to a single one of. We do not choose your board for you: the Analysis returns Blocked and names every board found, so you can send the one you meant. The same applies to an archive we cannot open as a zip, one that holds more files than we unpack, and one that expands beyond the size we unpack. A member that would be written outside the archive is not a refusal: it is skipped, listed in the report, and the board is migrated without it.
Proprietary rule engines and interactive-routing rule sets that have no KiCad representation (for example ActiveRoute rule sets).
External assets not embedded in the Source File (for example external STEP models or external libraries), unless you provide them when requested.
Embedded scripts, database links, version-control metadata, Altium "variants" beyond what the report states.
Manufacturing outputs (Gerber, drill, pick-and-place) — the Deliverable is a KiCad design, not a manufacturing package.
Any construct the report explicitly marks UNSUPPORTED.
What the report accounts for, domain by domain.
Within the Supported Scope, validation compares the Deliverable with the Source File for the domains below (Section 4 of the terms). The report states, per domain, which evidence category applies — the categories are defined in the report glossary.
- 01
components and designators;
- 02
nets and pin connectivity;
- 03
copper layers and layer mapping;
- 04
board outline and geometry;
- 05
footprints and pad geometry;
- 06
tracks, arcs, vias, fills and zones;
- 07
design rules and net classes (accounted for and mapped where a mapping exists);
- 08
differential-pair naming and membership;
- 09
3D model references (presence, not visual fidelity).
Frequently asked questions.
Is a .PcbDoc a text file I can open in an editor?
No. A modern .PcbDoc is a binary OLE2 compound file — a container of named storages and streams — and only EDA software that understands the Altium format can read it. Older boards were written as ASCII text or in a pre-V6 binary layout: the ASCII text form is converted to the binary form and reconciled against an independent count of your board before anything is migrated, while pre-Version-6 (Protel) boards are named as unsupported rather than silently skipped.
What is the KiCad equivalent of each Altium file?
A .PcbDoc becomes a .kicad_pcb board, a .SchDoc a .kicad_sch schematic, a .PcbLib a .pretty footprint library, a .SchLib a .kicad_sym symbol library, and a .PrjPcb a .kicad_pro project. An .IntLib splits into symbols and footprints.
Which Altium files can a Crosspad order migrate today?
At launch the Supported Scope is one Altium Designer .PcbDoc written by version 6 or later, in either form Altium writes — the binary file, or the ASCII text form, which is converted and checked against an independent count of your board before anything is migrated — or a .zip that carries exactly one such board, which is opened for that board and for nothing else. Up to 10 MB under the Terms — 4 MB through the browser today, because a larger upload is refused by the hosting platform before it reaches us — one Source File per single-project Order, targeting KiCad 10.0.5 (.kicad_pro and .kicad_pcb). Schematic documents, project files and libraries are outside the scope at launch, on their own and equally inside an archive: zipping a project gets the board in it migrated, not the project. The format pages document what those migrations involve. For a board over 4 MB, write to us and we will run it for you.
Why does KiCad open my old .PcbDoc as an empty board?
Because the file is most likely a legacy ASCII or pre-V6 Altium format. A standard migration expects the modern binary container, reads the older file, and produces nothing — with no error. Crosspad splits the two: the ASCII text form is converted to the binary form and reconciled against an independent count of the board before anything is migrated, while a pre-Version-6 (Protel) board is named as unsupported instead — and for that one the reliable remedy is to open the board in a current Altium Designer and re-save it.
See what your board contains — then what a migration keeps.
Open the board in the browser, or run the free analysis and get evidence about your own project.
The analysis is free.
Last updated 2026-09-05. Container facts are those implemented in Crosspad's in-browser reader; scope is quoted verbatim from the Commercial Beta Terms, which carry their own version and hash in the footer of /commercial-beta; KiCad importer facts are anchored to KiCad 10.0.6 (2026-08-29).