Migrate Altium libraries to KiCad — every footprint, symbol and pad accounted for.
KiCad reads your Altium libraries directly, and open-source tools convert them — the easy part is already solved. What no one proves is that the converted library is complete. An exotic pad, a custom stack, a symbol's parameters or its 3D placement can all go missing without a single error. Library files are outside the Supported Scope at launch; when library migration ships, Crosspad would verify your libraries against their source — every footprint, symbol and pad detected, repaired where it can be proven safe, the rest clearly flagged — so nothing disappears in silence.
Library files (.PcbLib, .SchLib, .IntLib) are outside the Supported Scope at launch — the free analysis names them as unsupported rather than guessing. The migration service processes an Altium .PcbDoc. This page documents how a library object would be reported when library migration ships.
A library that imports isn't a library that's been verified.
Basic library conversion is a commodity — since KiCad 8, KiCad reads Altium libraries directly, and open-source tools have done it for years. So you get something that looks like your parts. The problem is everything you can't see by scrolling the list: an exotic pad that arrived as the wrong shape, a symbol whose parameters didn't carry, a 3D body sitting offset from its pads, a custom pad stack that quietly didn't import. Most parts look right, and the missing ones surface at layout — or at the fab. Crosspad exists to check the whole library against your source and prove what came across, part by part, not just produce files that load.
A library that loads isn't a library that's verified.
Footprints, symbols and pads — accounted for, part by part.
Basic conversion is solved; completeness is the gap. Here is what a standard Altium → KiCad migration can silently leave behind in each — every item documented in KiCad's own import docs or public issue tracker, several of them structural limits rather than bugs — and what Crosspad checks against your source.
Footprints — geometry that looks right until it doesn't.
Basic footprint geometry imports well and keeps improving. The losses are at the edges — keepouts, layers, 3D and references — where a footprint that looks correct in the list isn't.
A footprint's polygon cutout can arrive as an over-broad keepout, throwing spurious DRC errors on copper that was fine.
A footprint layer with no clean KiCad equivalent can be silently remapped, and an invalid layer name has dropped geometry entirely.
A footprint's 3D body placement is read but not applied — the model can sit rotated or offset from its pads.
Imported footprint references have come across blank or as "UNK", so the part loses its identity in the library.
Crosspad checks every footprint against your .PcbLib source — pad-for-pad geometry, keepouts, layer mapping and 3D reference — repairs what it can prove safe, and flags the rest.
Symbols — the part is more than its outline.
The symbol graphic usually imports. What travels with it — parameters, models, orientation — is where a standard migration quietly thins out.
Symbols drawn from the IEEE standard set aren't imported at all — they simply don't come across.
The parameters, parameter sets and implementation maps a symbol carries — the fields your BOM and part choices depend on — aren't transferred.
A SPICE model attached to a symbol is parsed but not carried into simulation — the symbol imports, the model doesn't run.
A symbol can arrive with its rotation reported as 0°, silently re-orienting the part in the library.
Crosspad checks every symbol against your .SchLib source — graphic, pins, parameters, model links and orientation — and reports each field that carried, was rebuilt, or needs a decision.
Pads — where "not supported yet" is still true.
Pads are where the importer's honest limits bite hardest: some shapes and stacks are named as unsupported in KiCad's own docs and tracker, so they don't come across at all.
Pad shapes beyond circle, rectangle, octagonal and rounded-rectangle aren't imported — an exotic pad can arrive as the wrong shape or not at all.
Complex or custom pad stacks aren't supported and don't come across — a long-standing, still-open gap.
When a pad's layer has no clean KiCad equivalent, its per-layer geometry can collapse in the remap.
Crosspad checks every pad in your footprints against the source — shape, stack and per-layer geometry — names the ones KiCad can't represent as an engineering decision, and never counts an unmapped stack as "migrated".
Library-level failure modes reflect a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29). Native Altium library import landed in KiCad 8.0.0 and changes most releases; version-specific rows (e.g. symbol rotation #19630, footprint refs #18502) are noted, and this page is updated per release.
Why is my imported Altium library read-only?
Because KiCad opens it that way on purpose. Since KiCad 8 learned to read Altium libraries directly, it mounts a .SchLib or .PcbLib as a read-only source — you can browse it and drop its parts onto a board, but you can't edit a footprint or symbol in place, and KiCad won't write changes back into the Altium file. It isn't a broken import or a permissions glitch: the read-only state, and the clone-to-edit path around it, are documented in KiCad's own issue tracker and user forum. To get an editable library, you clone the imported one into KiCad's native format — and that's where the real question starts.
- 1
In KiCad's Symbol or Footprint Library table, select the imported Altium library.
- 2
Migrate it to a native KiCad library — a .kicad_sym symbol library or a .pretty footprint library.
- 3
Point your project at the cloned KiCad library. It's writable now — you can edit, add and version its parts.
Cloning unlocks editing; it doesn't prove the clone is complete. The copy you can now edit came through the same conversion as the read-only import — so an exotic pad, a symbol's parameters or a 3D placement can already be missing before you touch a thing (see what a standard migration leaves behind, above). Editing a library that quietly lost parts just builds on the gap. Before you commit to the cloned library, check it against your Altium source — every footprint, symbol and pad accounted for.
Every footprint. Every symbol. Every pad. Accounted for.
- 01ANALYZE SOURCE
Read your Altium libraries directly — every footprint, symbol, pad, parameter, model link and 3D reference in the .PcbLib / .SchLib / .IntLib.
- 02MIGRATE
Move the whole library set to KiCad, using the strongest strategy for each footprint, symbol and pad.
- 03COMPARE
Match the KiCad result back to the source, part by part: every footprint's geometry, every symbol's fields, every pad shape and layer.
- 04REPAIR
Correct discrepancies automatically, then re-parse and re-validate. A repair that can't be proven safe is rolled back and flagged, never silently kept.
- 05EXPLAIN
Produce an evidence report: which parts are verified, which were repaired, and which still need an engineering decision.
If Crosspad can't verify a footprint, symbol or pad came across correctly, it doesn't mark it safe.
The state each library object would be reported in.
Library files (.PcbLib, .SchLib, .IntLib) are outside the Supported Scope at launch — the free analysis names them as unsupported rather than guessing. The migration service processes an Altium .PcbDoc. This page documents how a library object would be reported when library migration ships.
| OBJECT | SOURCE | TARGET | WOULD BE REPORTED AS |
|---|---|---|---|
| Footprints (.PcbLib) | every footprint read | matched to source, or named where it can't be | VerifiedVERIFIED |
| Symbols (.SchLib) | every symbol read | matched to source, or named where it can't be | VerifiedVERIFIED |
| Symbol parameters | parameters read | rebuilt where dropped, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Pad shapes | shapes read | mapped where a KiCad shape exists; the mapping is stated | Expressed differently in KiCadTRANSLATED_EQUIVALENTLY |
| Custom pad stacks | custom stacks present | no KiCad equivalent — confirm a mapping | Needs your answerACTION_REQUIRED |
| 3D model placement | placement read | read, not applied — needs a judgment | Needs your callENGINEERING_DECISION_REQUIRED |
| IEEE-standard symbols | present in source | not imported — supply a replacement | Needs your answerACTION_REQUIRED |
| Footprint layer map | layer roles read | mapped; the mapping is stated | Expressed differently in KiCadTRANSLATED_EQUIVALENTLY |
Which libraries we account for — and which we won't pretend to.
Crosspad targets modern binary Altium libraries — footprint (.PcbLib), symbol (.SchLib) and integrated (.IntLib) libraries, typically alongside their project. Legacy ASCII and pre-V6 library files are named as unsupported, not silently skipped. Database-backed libraries (.DbLib) resolve their parts from an external database rather than the file itself — Crosspad names that dependency instead of pretending a self-contained library came across. And where a part has no clean KiCad equivalent — an exotic pad, an IEEE symbol, a custom stack — Crosspad marks an engineering decision and hands it to you, rather than quietly dropping it.
Frequently asked questions.
Can KiCad import an Altium library?
Yes — since KiCad 8, KiCad reads Altium symbol and integrated libraries directly, and open-source tools have converted footprint and symbol libraries for years. What none of them does is prove the converted library is complete — that every footprint, symbol and pad came across, and that the ones that changed are flagged. That's what Crosspad checks.
How do I convert an Altium library to KiCad?
The conversion itself is a solved, commodity step — KiCad reads Altium libraries directly. The hard part is knowing whether the result is complete. Library migration is not live yet: at launch the free analysis runs on a .PcbDoc and names a .PcbLib, .SchLib or .IntLib as unsupported rather than guessing. When library migration ships, Crosspad will check the converted library against its source part by part and report what's verified, what it repaired, and what it left for a decision.
What does a standard Altium → KiCad library migration lose?
Most often: exotic pad shapes and custom pad stacks, IEEE-standard symbols, symbol parameters and parameter sets, SPICE model links, 3D placement, and footprint layer and keepout mapping. Each is documented in KiCad's own import docs or public tracker.
Are Altium footprints compatible with KiCad?
Largely, yes — basic footprint geometry imports well and keeps improving. The gaps are at the edges: custom pad stacks, exotic pad shapes, layer remapping and 3D placement. Crosspad's job is to tell you exactly which of your footprints hit those edges, not to assume they didn't.
Does Crosspad guarantee my library migrates perfectly?
No one honestly can. What Crosspad guarantees is that nothing in the library is lost in silence: every footprint, symbol and pad is detected, repaired where it can be proven safe, or clearly flagged for a decision.
Can Crosspad handle a single footprint or symbol, not a whole library?
Not yet — library files are outside the Supported Scope at launch, whether it's one part or a whole set. When library migration ships it will treat both the same way: footprints, symbols and pads verified part by part against the source. Today the free analysis runs on a .PcbDoc.
Why is my imported Altium library read-only in KiCad?
By design. Since KiCad 8 reads Altium libraries directly, it mounts them as a read-only source — you can browse and place parts, but you can't edit a footprint or symbol in place, and KiCad won't write back into the Altium file. To make it editable, clone the library into a native KiCad format. The behavior is documented in KiCad's issue tracker and user forum (KiCad #18452, forum thread 38443).
How do I edit a read-only imported Altium footprint or symbol?
Clone the imported library to a native KiCad library — a .kicad_sym for symbols or a .pretty for footprints — then edit the writable copy. One caution: the clone inherits whatever the conversion dropped, so check it against your Altium source before you build on it. When library migration ships, Crosspad will verify the cloned library part by part and report what carried, what it repaired, and what still needs a decision.
Does cloning a read-only Altium library make it complete?
No — cloning only makes it writable. It doesn't add back an exotic pad, a symbol parameter or a 3D placement the conversion may have already dropped; completeness is a separate question. That's the one library migration will answer when it ships: proof that every footprint, symbol and pad in the clone matches your Altium source, with the rest clearly flagged. It is not live today.
Know what your libraries would keep, repair and flag — before you commit.
Library migration is not live yet. When it ships, this is the evidence it would produce — what a KiCad migration keeps, what it repairs, and what it flags for you, every footprint, symbol and pad. The free analysis runs on a .PcbDoc today.
Library files (.PcbLib / .SchLib) are outside the current supported scope — the free analysis names them as unsupported rather than guessing. This page documents what changes when you move them.