How Altium fills migrate to KiCad — and where they silently break.
A copper fill isn't just a shape. It carries a net, a layer, and the clearance that keeps it manufacturable and connected. A standard Altium → KiCad migration can keep the shape and quietly lose the rest. Crosspad decodes the fill format, detects every fill that was dropped or altered, restores the ones it can prove safe with their net, and re-validates — so a fill can't go missing in silence.
A fill that opens isn't a fill that's still connected.
Copper fills are the part of a board most likely to look right and be wrong. The copper is visibly there on screen — but the net it belongs to, the soldermask relief around it, and the clearance KiCad uses to recompute it can all have changed on the way over. And KiCad refills zones automatically. So a board that opened green can, one refill later, have a ground plane that no longer connects. That isn't a hypothetical — it's a documented failure mode (KiCad #18408).
The copper is still on screen. The connection isn't.
Why are copper fills so hard to migrate?
Altium doesn't store a fill as a simple polygon. It stores it in a binary structure — one that changed across two eras of the file format — carrying the fill's net association, its layer, and a transform, because a fill can be rotated or placed relative to a component. Worse, three different Altium objects look almost identical on screen and mean different things: solid Fills, polygon Regions, and Polygon Pours. A migration that treats a fill as “just a shape” copies the geometry and drops the meaning: which net the copper belongs to, whether it's a free pour or a fill owned by a component, and the relief and clearance that decide whether the copper is still manufacturable — and still connected — after a refill.
Crosspad's own fill research decoded that binary format across both eras — including transformed and rotated fills — so a migration can be checked as connected copper on a named net, not as anonymous shapes.
- The net
A fill belongs to a net. Lose the association and it's dead copper — or a short waiting for DRC to miss it.
- The layer
A fill lives on a specific copper or mask layer. A remapped or dropped layer moves or erases it.
documented: KiCad #17351 / #18756 - The relief & clearance
Soldermask relief and zone clearance decide manufacturability — and whether a refill keeps the connection.
documented: KiCad #13750 / #18408
What a standard Altium → KiCad migration quietly does to your fills.
These aren't hypotheticals — each is documented in KiCad's own public tracker, as of KiCad 10.0.6 (2026-08-29). Crosspad checks for every one against your source.
- Soldermask relief is dropped
The relief that keeps a fill clear of the solder mask can be lost on import — changing what actually gets fabricated.
documented: KiCad #13750 - Zone clearances come across wrong
A zone's clearance can import incorrectly — and because KiCad recomputes zones on refill, a routine refill can silently disconnect copper.
documented: KiCad #18408 - Cutouts become over-broad keepouts
A polygon cutout can arrive as a keepout larger than intended — producing spurious DRC errors, or masking real ones.
documented: KiCad #15587 - A fill's layer is remapped or dropped
A copper or mask layer with no clean KiCad equivalent, or an unusual name, can be remapped or silently dropped — taking its fills with it.
documented: KiCad #17351 / #18756 - Legacy ASCII boards import as nothing
Older ASCII PcbDoc files — fills and all — can import as an empty board, with no error at all.
documented: KiCad #18467
Fill/zone import behavior is version-specific and changes most releases. This page is dated and refreshed per KiCad point release.
How does a clean import silently disconnect a plane?
- 01
A standard migration imports the board. It opens. The copper pour is visibly there; DRC looks fine.
- 02
But the zone's clearance didn't come across correctly — a documented import fault (KiCad #18408).
- 03
You refill the zones — or KiCad refills them automatically — the ordinary thing every engineer does before a fab release.
- 04
With the wrong clearance, the recomputed pour pulls back from the pads it used to connect. The plane splits; a net that was solid is now broken.
- 05
Nothing warned you, because the board was “imported successfully.”
This is the exact class of failure Crosspad exists to catch: it compares your fills back to your Altium source and flags a fill whose connectivity changed — instead of trusting that copper on screen is copper that's connected.
Every fill, on its net, accounted for.
- 01DECODE
Read the fills directly from your Altium source — solid fills, regions and polygon pours — with their net, layer and transform, across both eras of the format.
- 02COMPARE
Match every source fill to the migrated result: is it present, on the right layer, on the right net, with its connectivity intact?
- 03RESTORE
Where a fill was dropped — including component-owned fills — restore it with its net, then re-parse and re-validate. A restoration that can't be proven safe is rolled back and flagged, never silently kept.
- 04FLAG
Where equivalence can't be proven — a clearance whose intent can't be matched, a cutout that changed meaning — surface it as an engineering decision instead of quietly accepting the geometry as correct.
- 05EXPLAIN
Report every fill's status: verified, restored, or left for a decision.
If Crosspad can't prove a fill is still connected on its net, it doesn't mark it safe.
Crosspad's fill checks are stress-tested by mutation — deliberately damaging fills in known-good boards and confirming each change is caught — so a dropped or altered fill isn't allowed to pass as fine.
Know exactly what happened to every fill.
| OBJECT | SOURCE | TARGET | REPORTED AS |
|---|---|---|---|
| Copper pours (zones) | GND, PWR planes | present, nets verified | VerifiedVERIFIED |
| Component-owned fills | dropped on import | restored with net, revalidated | Fixed and re-checkedREPAIRED_AND_REVALIDATED |
| Soldermask relief | defined | differs from source — confirm the relief | Needs your answerACTION_REQUIRED |
| Zone clearance (net-tied) | rule-bound | intent unmatched | Needs your callENGINEERING_DECISION_REQUIRED |
| Cutout → keepout | polygon cutout | over-broad — confirm the region | Needs your answerACTION_REQUIRED |
What we account for in fills — and what we don't pretend to.
Crosspad decodes fills from modern Altium boards, version 6 or later (.PcbDoc / .PrjPcb) — 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. So the fills in an ASCII board that a standard migration drops entirely (KiCad #18467) are decoded and accounted for, not lost; pre-V6 (Protel) boards are named as unsupported, not silently skipped. Where a fill's clearance or relief intent can't be proven equivalent in KiCad, Crosspad marks it an engineering decision rather than quietly accepting the geometry as correct.
Frequently asked questions.
Do Altium copper fills import into KiCad?
Mostly the geometry does. What a standard migration can lose is the meaning around it: the net a fill belongs to, its soldermask relief (KiCad #13750), and the zone clearance a refill depends on (KiCad #18408). Crosspad checks each fill against your source.
Why does my copper plane disconnect after import?
A common cause is that the zone's clearance imported incorrectly (KiCad #18408). When the zones are refilled — which KiCad does automatically — the pour recomputes with the wrong clearance and pulls back from pads it used to connect. Crosspad compares fills to your Altium source and flags any whose connectivity changed.
What's the difference between an Altium fill, region and polygon pour?
Three different Altium objects that look similar on screen but mean different things — solid fills, polygon regions, and polygon pours — each carrying a net and a layer. A migration that treats them all as plain shapes loses that distinction. Crosspad decodes each so it can verify the copper is still on the right net and layer.
Does a fill that looks right mean the migration is safe?
No. Copper on screen isn't proof of connectivity. Crosspad marks a fill safe only when it can prove it's present, on the right layer, and connected on its net.
Can Crosspad guarantee no fill is lost?
No one honestly can. What Crosspad guarantees is that a fill can't go missing in silence: every fill is detected, restored where it can be proven safe with its net, or clearly flagged for a decision.
See what happened to every fill — before you trust the board.
Point Crosspad at an Altium board and get evidence of which fills survived, which were restored with their net, and which need a decision.
Free analysis on one Altium .PcbDoc — one board file, not a project. Files are processed as described in our Security policy.
Fill behaviour reflects a standard Altium → KiCad migration as of KiCad 10.0.6 (2026-08-29). It changes most releases; version-specific claims above are scoped, and this page is updated per release.