Open a PcbDoc — and see what a KiCad import would drop.
Crosspad renders and inventories your Altium board in the browser — every layer, net, pad stack, zone and keepout — then names what a standard KiCad import is documented to silently drop.
A viewer shows you the board. It doesn't show you what a migration would drop.
Every free PcbDoc viewer shows you the board; none of them tells you what you'd lose moving it to KiCad. The free viewers render your .PcbDoc beautifully — copper, silk, 3D, the netlist. What none of them answers is the question you actually have if KiCad is where this board is going: what survives the trip? A zone whose relief a standard import drops, a keepout that widens into false DRC, a layer with no clean equivalent, a custom pad stack that doesn't come across — a renderer shows none of that, because the board still looks fine. Crosspad inspects the board for exactly those, against the failure modes documented in KiCad's own tracker, and names them before you commit.
Rendering the board isn't the same as knowing it will migrate.
Inventory the whole board. Flag what a migration would cost.
Open a .PcbDoc above and it does three things a plain viewer doesn't — and hands the fourth to the readiness scan:
Tracks, arcs, pads with their real geometry, vias, fills, silkscreen and designator text, pour outlines, regions and the board outline — read straight from the .PcbDoc on your machine. Round, oval and rectangular pads are decoded from the file; an uncommon pad shape is drawn as its bounding rectangle rather than guessed at.
Every component, net, pad, via, track, arc, fill, text item, pour, region and layer in use — counted from the file, not just drawn — and the streams the viewer reads but doesn't render, named as such.
Hover any object for its layer, net and width; click to inspect it; search nets and designators; highlight a net or a component; measure in mm and mil; flip to the bottom side.
The readiness scan is a separate, free step at /migrate: drop the same board there and the engine flags what a standard KiCad import is documented to drop — named against your specific file, never waved through.
If the inspector can't confirm a board object is safe to migrate, it flags it — it doesn't wave it through.
If you can't open your own board, a migration is already on the table.
Altium ships no native macOS or Linux build. If you're on a Mac or on Linux, you can't open your own .PcbDoc in the tool that made it — which is usually why the board is on its way to KiCad in the first place. Open it here to read the design, then run the readiness scan to see exactly which parts of it a standard KiCad import would keep, change, or drop.
Open and inventory a .PcbDoc without a Windows VM or a Parallels licence — then check what a KiCad import would carry across.
Read the board natively on the OS you already run KiCad on — and get the migration-readiness verdict for the exact file you'd import.
What a standard KiCad import quietly leaves off the board.
These aren't hypotheticals — each is documented in KiCad's own import docs and public issue tracker, and several are version-specific (documented against KiCad 10.0.6, 2026-08-29). Crosspad's readiness scan checks every one against your source .PcbDoc before you migrate.
Soldermask relief can be lost and zone clearances can arrive wrong — so a routine refill silently disconnects copper.
Polygon cutouts can come across as over-broad keepouts, triggering spurious DRC errors on copper that was fine.
A layer with no clean equivalent can be silently remapped, and an invalid layer name has dropped Edge.Cuts — the board outline itself.
Complex or custom pad stacks aren't supported and don't come across — a long-standing, still-open gap.
Channel suffixes get stripped (C33A / C33B → C33), collapsing distinct parts into duplicate references and breaking the board's BOM and netlist.
Clearance and width classes survive, but which nets belong to them can be dropped — so the copper rules constrain nothing.
Text on copper or mask layers can arrive mispositioned — a shifted part number or polarity mark you won't catch by eye.
An older ASCII .PcbDoc can import as nothing at all — no board, and no error to tell you.
Board-level failure modes reflect a standard Altium → KiCad import as of KiCad 10.0.6 (2026-08-29). Behavior changes most releases; version-specific rows (e.g. copper/mask text #24504, seen in 10.0.3) are noted, and this page is updated per release.
The board inventory — counted from the file you open.
Open a board above and this table fills in from the parsed file: what's on the board, what the viewer draws, and which streams it reads but doesn't render. Counts, not verdicts — the readiness verdict comes from the scan.
| OBJECT | IN THIS BOARD | IN THE VIEWER |
|---|---|---|
| Components / footprints | — | Designator, footprint, side · highlight by designator |
| Nets | — | Named on every track, arc, pad and via · highlight by net |
| Pads | — | True shape, size, rotation, hole |
| Vias | — | Diameter, hole, layer span |
| Tracks | — | Per layer, true width |
| Arcs | — | Per layer, true sweep and width |
| Fills | — | Rectangles with rotation · keepouts marked |
| Text | — | Silkscreen and designator strings |
| Copper pours | — | Outline and net (the filled copper is not reconstructed) |
| Regions | — | Outline with cut-outs · keepouts marked |
| Layers in use | — | Toggle, dim, flip to the bottom side |
| Present in the file, not rendered by this viewer | — | — |
Viewer and inventory are live.
The surface above reads your .PcbDoc directly in your browser — tracks, arcs, pads, vias, fills, silkscreen text, pour outlines, regions and the outline — with a layer panel, inspect, search, measure and flip. The migration-readiness verdict is a separate step: drop the same board again at /migrate — one .PcbDoc, up to 4 MB.
Need what the viewer doesn't draw? Here's the honest way.
The viewer renders the board's geometry — if you need what it doesn't draw (3D bodies, design rules, dimensions, the filled copper of every pour), there's a straight answer that isn't "just install Altium." Our guide walks the real options for opening the file on Windows, macOS and Linux, and what each one does and doesn't show you.
Frequently asked questions.
Can I open a .PcbDoc file without Altium?
Yes. Crosspad's viewer reads the .PcbDoc directly in your browser — no Altium licence, no install, nothing uploaded — and inventories the board as it draws it. The migration-readiness scan at /migrate then flags what a standard KiCad import is documented to drop from that exact file. Our guide covers every other way to open the file.
Is there an Altium PCB viewer for Mac or Linux?
Altium ships no native macOS or Linux build, which is exactly why Mac and Linux engineers end up moving boards to KiCad. Crosspad opens a .PcbDoc in the browser on either OS; the readiness scan at /migrate then shows what a KiCad migration would keep, change or drop for that specific file.
Is this just another PcbDoc viewer?
No. Free renderers (Altium 365, MakerSuite, ECAD Forge) show you the board — they render copper, silk and 3D well. Crosspad's inspector answers a different question: what survives a move to KiCad? It inventories the board and flags the objects a standard import is documented to silently drop.
What does a standard KiCad import drop from a PcbDoc?
On the board, most often: copper fills and zone clearances (so a refill can disconnect copper), keepouts, layer mapping and the board outline, custom pad stacks, copper/mask text position, net-class membership, and multi-channel reference designators. Each is documented in KiCad's own tracker or import docs.
Does the viewer upload my file?
No. The viewer parses and renders your .PcbDoc entirely in your browser — nothing is uploaded and no account is required. The readiness scan at /migrate is a separate step you choose to take.
Can it open a legacy ASCII or pre-V6 .PcbDoc?
Not in the viewer: it draws the binary form only, and says so the moment you drop the file. A migration is a different scope — /migrate does take the ASCII text form, converting it to the binary form and reconciling it against an independent count of your board before anything is migrated; a pre-V6 (Protel) board stays unsupported. A standard KiCad import can read an old ASCII .PcbDoc as nothing at all, with no error (KiCad #18467); nothing here is passed silently.
Open your PcbDoc — and see what a migration would cost before you commit.
Inventory the whole board in your browser, then drop the same board at /migrate for a free readiness verdict: what's ready, what needs review, and what a standard import would drop.
The analysis takes one .PcbDoc, up to 4 MB. Sign in with your email; nothing is charged until you unlock a migration.