Copper layers: the circuitry itself

Copper layers are the board’s wiring: tracks, pads, vias and poured planes, etched from the copper foil. A simple board has two — top and bottom — and multi-layer boards add inner copper layers that you will never see on the finished product but which carry signals and power planes inside the stack. In a viewer, copper is the densest, busiest artwork: fine tracks routing between pads everywhere the design goes. Copper is the reference layer for the whole set — drills must land on its pads, mask openings must expose the right parts of it — which is why alignment checks like loading and aligning Gerber layers always start from copper.

Solder mask: the protective skin

Solder mask is the coloured coating — most often green, but any colour you have seen — that covers the board and insulates the copper, leaving openings only where solder joints belong: pads, vias the design wants exposed, test points. Its Gerber file therefore looks like a near-solid sheet with holes punched in it, the photographic negative of the pad pattern. That inversion confuses first-time viewers: the mask file shows mostly what will be covered, and its information lives in the openings. Every opening should sit over copper that is meant to be solderable; mask accidentally covering pads is a classic assembly disaster that a stacked view exposes instantly, since the pads simply vanish under the sheet.

Silkscreen: the printed legend

Silkscreen — also called legend — is the white (usually) printed text and graphics on the board’s surface: component outlines, reference designators like R12 and U3, polarity marks, logos and revision notes. It carries no electrical function at all, which makes it the easiest layer to recognise: sparse ink floating over empty space, readable as language and symbols rather than circuitry. Its checks are human ones. Text must not print over pads (ink on a solder joint is a defect), designators should sit beside their components rather than under them, and the bottom-side legend, if any, should read correctly for the side it is on — a mirrored silkscreen is a frequent export slip that only a look at the actual layer will catch.

Solder paste: the assembly layer

The paste layer describes where solder paste is deposited through a stencil before surface-mount components are placed and reflowed. In the viewer it is the most minimal of the set: only the surface-mount pads appear, as neat arrays of rectangles and circles matching the footprints — nothing for through-hole parts, nothing for tracks. A board with no surface-mount components legitimately has no paste layer, which is a fact to know before reporting one missing. Where paste exists, its check is correspondence: every surface-mount pad on the copper should have a matching paste opening, in the same place, at a sensible size.

Outline: where the board ends

The outline — also called the profile, edge or board shape layer — is a simple closed line (or set of lines) defining the board’s boundary and any internal cutouts or slots. It looks empty compared to the others, and it is one of the most important files in the package: the fab cuts to it, quotes from its dimensions, and judges whether everything else fits inside it. Check that the profile is truly closed, that it measures to the designed size — the measurement routine is in measuring distances in Gerbv — and that no copper, text or stray shape sits outside it.

Recognising layers in Gerbv

Put together, recognition is a visual skill with reliable tells: copper is dense and everywhere, mask is a solid sheet with pad-shaped holes, silkscreen is sparse readable marks, paste is only footprint pads, outline is a bare closed profile, and the drill file — Excellon, not Gerber — is a field of circles that must register with the copper. Load the set in Gerbv (free from the download page), toggle layers over the top copper one at a time, and each type announces itself. The Gerber viewer hub ties the whole inspection together into a pre-order routine.

Frequently asked questions

How many copper layers does a board have?

At minimum the two outer sides, top and bottom. Multi-layer boards add inner copper layers for signals and power planes — each is its own Gerber file in the package, recognised by dense track-and-pad artwork like the outer copper.

Why does the solder mask file look almost solid?

Because the mask covers nearly everything: the file describes the coating, and its meaningful features are the openings left over pads and other solderable points. It is effectively the negative of the pad pattern, which is normal and correct.

Which layer defines the board’s size and shape?

The outline (profile) layer — a closed line the fab cuts to. Measure it in the viewer against your design dimensions, confirm the profile is closed, and check that no artwork from any other layer falls outside it.

The Gerber model: images plus attributes

A Gerber package is a folder, not a document. Each file is a complete, self-contained image of one layer — top copper, bottom copper, mask, legend, paste, outline — drawn with apertures, and the drill data rides alongside as a separate Excellon file. Gerber X2’s contribution to this model is the attribute system: inside each file, structured metadata records the layer’s function and can attach part and net information to the objects drawn. But the model stays plural and image-first. The board is the sum of its layers, and anything the layers do not say — the stackup order and materials, the finish, the assembly data — travels in other documents: a fabrication drawing, a readme, a BOM, a pick-and-place file.

The IPC-2581 model: one XML, whole intent

IPC-2581 starts from the opposite end. It is a single XML file built on an industry standard, designed so that the one document can describe the board comprehensively: the layer images, the stackup that orders and specifies them, the components and bill of materials, and the assembly and test intent alongside fabrication. Where Gerber says “here are the pictures, with labels”, IPC-2581 says “here is the board, described”. The appeal is structural: nothing essential has to live in a side document that can be forgotten, version-skewed or misread, because the format has a place for it inside the file itself.

Why most fabs still ask for Gerber

If one format carries more, why does the industry default remain Gerber? The honest answer is ecosystem, not merit in the abstract. Gerber has decades of installed tooling behind it: every CAD package exports it, every fab imports it, every viewer — including Gerbv — reads it, and every engineer’s checking habits are built around it. A fab’s request is really a statement about its own pipeline: send the format our import, quoting and CAM preparation are proven on. Some fabs accept IPC-2581 as well, and if yours does and your CAD tool exports it well, using it is a legitimate choice. But “supported somewhere” is not “accepted everywhere”, and the safe universal deliverable remains a checked Gerber set. Always follow your specific fab’s stated preference over any general argument — including this one.

What this means for checking your files

Your verification routine follows the model of the files you actually send. Send Gerber, and the check is the familiar one: open the set in Gerbv (from the download page), stack the layers, confirm the drills register, measure the outline, read the aperture and drill statistics — the flow on the Gerber viewer hub and in the pre-order checklist. Gerbv views Gerber RS-274X (including X2 files, whose images it renders) plus Excellon and CSV data; it does not read IPC-2581, because it is a Gerber viewer and the XML model is a different country. If you send both formats to a fab that accepts both, check both — the Gerber pass in a viewer, and the IPC-2581 export by whatever tooling your flow provides — because a correct Gerber set says nothing about a stale XML export sitting beside it.

The practical bottom line

Think of the choice as images-with-labels versus a single structured description, and of your fab’s intake desk as the referee. Gerber X2 is the lingua franca: universally exportable, universally importable, and checkable in free tools on any desktop. IPC-2581 is the more ambitious container, available where the toolchain at both ends supports it. For most readers, most weeks, the winning move is unglamorous: export clean Gerber X2, name the files clearly, include the stackup and finish in your order notes, and verify the exact set in a viewer before it leaves your machine.

Frequently asked questions

Is IPC-2581 better than Gerber X2?

They are different models rather than a ranking. IPC-2581 carries more of the board’s intent — stackup, components, BOM — in one XML file. Gerber X2 is layer images plus attributes, and wins on universality: every CAD tool exports it and every fab accepts it. Your fab’s preference decides.

Can Gerbv open IPC-2581 files?

No. Gerbv is a Gerber viewer: it reads Gerber RS-274X files (including Gerber X2, whose layer images it renders), Excellon drill files and CSV pick-and-place files. IPC-2581’s single-XML model needs tooling built for that format.

If my fab accepts both, which should I send?

Send the one your own workflow can verify best, and check exactly what you send. Many engineers send the Gerber set they have inspected layer by layer in a viewer, since that verification habit is proven; if you send IPC-2581, verify that export through its own tooling.

The 2026 revival (current era)

• v2.13.0 — March 20, 2026. The current stable release. First release with native Windows and macOS builds: an NSIS Windows installer, a native MSYS2 UCRT64 Windows ZIP, an official macOS ZIP, plus Ubuntu 22.04 / Debian 13 .deb and Fedora 43 .rpm packages. Six assets, each with a published SHA-256. Covered in depth in Gerbv 2.13.0: first native Windows and macOS builds.
• v2.12.0 — March 8, 2026. DXF export became built in on all platforms; new optimised SVG export with optional Inkscape layers. Four assets: Debian, Fedora and Ubuntu packages and a Windows amd64 ZIP. That Windows ZIP (gerbv_v2.12.0_.Windows.amd64.zip, 41,497,359 bytes) does have a published digest — SHA-256 90409c5a92ef885f8dfa2b33112deb4b36122d6110bf5576c6669d151d43d576 — noticeably larger than the slim 2.13.0 Windows builds that replaced it.
• v2.11.1 — March 2, 2026. A quick follow-up release in the same four-asset layout.
• v2.11.0 — February 28, 2026. The comeback release: the first after the project’s CMake rewrite of its build system, introducing the modern packaging pattern (.deb, .rpm, Windows ZIP; Windows build is 64-bit).

The quiet years: 2.10.0 and 2.9.x

• v2.10.0 — August 21, 2023. The last release before the long pause — a single Windows amd64 ZIP asset on GitHub. Roughly two and a half years separate it from v2.11.0, which is why older pages sometimes describe Gerbv as abandoned; that description is outdated.
• v2.9.8 — June 24, 2023, preceded by v2.9.7 (May 25, 2023) and v2.9.6 (January 4, 2023). Each shipped with a single Windows amd64 ZIP on the GitHub repository.

A checksum warning for this era: the older 2.9.x and 2.10.0 Windows ZIPs carry no published SHA-256 digest in the GitHub release metadata. Any website that prints a tidy hash table for those files invented it. If you run an old build, obtain it from the GitHub releases archive itself and treat the source as the verification — and understand that you are running it without a publisher checksum to check against. Current builds do not have this problem: every v2.13.0 asset on the download page lists its real digest.

The SourceForge era

Before GitHub, Gerbv lived on SourceForge, where it was registered in 2001. Its announcements there mark the early milestones — 2.0.0 in January 2008 brought the much more powerful layer-control GUI, Cairo rendering with transparency, report windows and command-line export; 2.1.0 in September 2008 added RS-274X and Excellon export (format translation and file “cleaning”), object selection with deletion, panelisation from the command line, and the libgerbv library split. The SourceForge files area still serves tarballs from that era (up to the 2.3.0-era sources), and the project page shows a 4.6 out of 5 rating from 26 ratings and 1,247,968 all-time downloads — historical figures for the whole project since 2001, not numbers for any current version. SourceForge itself now points visitors to the modern official site, and current releases ship only via GitHub.

Where to get older versions

Every release discussed here is archived on the project’s GitHub Releases page (github.com/gerbv/gerbv/releases), newest first; scroll back or use the tags to reach 2.12.0, 2.11.x, 2.10.0 and the 2.9.x line. That archive is the only source this site recommends for old binaries — it is the project’s own channel, so an old file there is as official as an old file gets. For current use, though, there is rarely a reason to go back: v2.13.0 is the stable release, with per-platform guides for Windows, macOS and Linux, plus the portable Windows ZIP.

The Windows 7 exception

The one deliberate reason to install an old Gerbv is Windows 7. The upstream README is explicit: Windows 7 is supported only up to release 2.8.0. The 2026 Windows builds are 64-bit, tested on Windows 10. So a Windows 7 machine should take 2.8.0 (or older) from the releases archive, accepting that it misses the CMake-era packaging, the built-in DXF export from 2.12.0, and the native-build improvements of 2.13.0. On any supported system, install the current release instead — and if you are not sure which version you have, the timeline above plus the download page will tell you how far behind you are.

Frequently asked questions

What is the latest version of Gerbv?

v2.13.0, released on March 20, 2026. It followed three other releases in three weeks — v2.11.0, v2.11.1 and v2.12.0 — after a quiet period stretching back to v2.10.0 in August 2023.

Where can I download older Gerbv versions?

From the archive on the project’s official GitHub Releases page, which keeps every release from the current line back through 2.9.x and beyond. SourceForge still hosts only the legacy, 2.3.0-era files.

Which Gerbv version should Windows 7 users install?

2.8.0 or older — upstream supports Windows 7 only up to that release. Also note that old 2.9.x/2.10.0 Windows ZIPs have no published SHA-256 digest, so they cannot be checksum-verified the way 2.13.0 assets can.

Draws and flashes: the two moves

Apertures are used in exactly two ways. A draw sweeps the aperture along a line or arc, like dragging a pen: a round aperture drawn along a path makes a track with rounded ends, of the aperture’s width. A flash stamps the aperture once, at one coordinate, like a rubber stamp: that is how pads are made — the aperture’s shape becomes the pad’s shape exactly. Much of Gerber literacy is seeing a board in these two moves: tracks are draws, pads are flashes, and large copper areas are built either from many draws or from filled outlines the format calls regions. When something renders oddly, asking “is that a draw or a flash, and with what aperture” usually localises the problem.

The standard shapes

The format defines a small family of standard apertures, each described by a few parameters in the file’s aperture definitions. The circle is the workhorse — a diameter, optionally with a hole in the middle — used for round tracks ends, vias and round pads. The rectangle adds width and height and is the natural stamp for rectangular surface-mount pads, again optionally with a hole. The obround — a rectangle with semicircular ends, like a stadium outline — suits oval pads and slot-like features. A regular polygon form exists for the rarer cases that need one. These four cover the overwhelming majority of what real boards contain, and each is a complete, precise description: shape plus dimensions, defined once in the file header and then referenced by number everywhere it is used.

Macros: when standard shapes are not enough

Some shapes refuse to be a circle or a rectangle: a thermal relief pattern in a ground plane, a crosshair target, a pad with a notch. For those, the format provides aperture macros — small recipes that build a custom shape from primitive elements, with parameters the file can set per use. A macro is defined once and instantiated with different sizes, which keeps files compact and shapes consistent. In the viewer, macros are invisible as a mechanism — you simply see the resulting shape — but they explain why a statistics report may list a macro where you expected a simple pad, and why a very old or minimal tool in the chain occasionally renders a custom shape differently from a full viewer. In Gerbv the shapes render as specified; the macro machinery only becomes your concern when a shape on screen does not match the design, and its definition is the first place to look.

Reading the aperture-usage report in Gerbv

Gerbv opens report windows with statistics about the Gerber codes in use, including an aperture-usage view: which apertures a layer uses, and how often each is flashed or drawn. This is a surprisingly practical audit. A pad aperture flashed a plausible number of times agrees with your component count; an aperture used exactly once in a design with no one-off part is a question worth asking. A track-width aperture that appears in the report but not in your design rules points at an export setting. And a layer whose report lists no pad apertures at all is not a copper layer, whatever its filename claims — one of the fastest content checks available when a set arrives with cryptic names. Pair the report with the visual stack from the download page build and the identification routine in loading and aligning layers, and few layer mysteries survive. The Gerber viewer hub puts this in the overall checking flow.

Why apertures matter beyond curiosity

Apertures are where design intent meets manufacturing reality. The fab’s equipment reproduces the shapes your file defines — a pad that is the wrong aperture is the wrong pad on every board in the batch, rendered faithfully. Fine features push the other way: an aperture smaller than the process handles becomes a conversation with the fab, not a viewer problem. You cannot edit your way out of either in a viewer, and Gerbv does not pretend otherwise — but seeing the shapes, and reading the report of how they are used, is how you catch the problem while it is still a file and not a shipment.

Frequently asked questions

What is an aperture in a Gerber file?

An aperture is a named shape — defined once with its dimensions — that the file’s commands use to draw the board: swept along a path to draw a track, or flashed at a point to stamp a pad. Circles, rectangles, obrounds and custom macros are the standard kit.

What is the difference between a draw and a flash?

A draw moves the aperture along a line or arc, producing a stroke of the aperture’s width — that is how tracks are made. A flash stamps the aperture once at a coordinate, producing a shape identical to the aperture — that is how pads are made.

What does Gerbv’s aperture-usage report tell me?

It lists which apertures a file uses and how often each appears. That turns into a quick audit: pad counts that match your components, unexpected one-off shapes worth questioning, and missing aperture types that betray a mislabelled layer.

What a pick-and-place file contains

A pick-and-place file is a centroid file: for each component, it records the position of the part’s centre — its XY coordinates — in the same board coordinate space as the Gerber data. Depending on the exporting tool, the file may also carry each part’s reference designator, its value or package, and its rotation, which is why the format travels under several names: XY, XYRS and CSV pick-and-place files all appear in the project’s documentation history, and the man page describes pick-and-place input as XY (centroid) files produced by the PCB design program. The essential point for viewing is that the data is positional and tabular, not graphical: until something draws it over the board, an origin slip or mirrored export hides inside a perfectly plausible-looking spreadsheet of numbers. Gerbv’s contribution is exactly that drawing step — positions become visible objects, in registration with the copper they belong to.

Loading the pick-and-place layer over the board

Build the board stack first — copper layers, mask and outline, following loading and aligning Gerber layers — then open the CSV pick-and-place file from the main window so it joins the layer list as its own layer, stacked where you can toggle it over the top copper and silkscreen. If you opened the fabrication folder in one step, remember that Gerbv loads the loadable files it finds by content in alphabetical order, so the position file is already present and simply needs to be identified in the list. Give the layer a colour nothing else uses; component positions are sparse points compared with the dense copper, and a distinct colour keeps them legible without needing to hide the layers beneath. Start, as with drills, at the whole-board view: the pattern of positions should read as the board’s component layout — dense where the design is dense, empty where it is empty, everything inside the outline. That first glance is the audit’s foundation, because the common pick-and-place failures are all visible at exactly this scale.

Reading the overlay: the assembly sanity checks

Now interrogate the pattern. Coverage: every populated area of the board should carry positions, and every position should sit on a component’s pads — toggle the pick-and-place layer over the top copper and check the connectors and large parts first, because their centres are unambiguous, then sweep the fields of small parts where a missing position is easy to miss. Orientation plausibility: where positions form rows and arrays, they should follow the orderly pattern of the footprints beneath them; a single position floating off-grid, or a cluster at the board origin, usually means one part was placed in the design at a stray location or exported from a different origin. Inside the outline: no position should fall outside the board edge or inside a cutout — the assembly equivalent of the drill check in viewing Excellon drill files. Side awareness: know whether the file contains top-side parts, bottom-side parts or both, and view bottom-side positions against the bottom copper, not the top. And where the exported file includes designators, cross-check a few against the silkscreen layer — the position the file calls one reference should sit on the footprint the silkscreen labels with that reference.

Scale, origin and mirror: the three failures this catches

Pick-and-place exports fail in the same three geometries as drill files, and the overlay exposes each one instantly. A scale failure — positions interpreted in the wrong unit — spreads the components across an area 25.4 times too large or compresses them into one corner, invisible in the CSV and grotesque in the viewer. An origin failure keeps the pattern’s shape perfect but shifts it as a block relative to the pads, which is why the check must be done against the copper and never by looking at the position layer alone. A mirror failure — most often a bottom-side file exported as if viewed from the top — produces a pattern that matches the board only when flipped, with symmetric areas looking deceptively fine and asymmetric features betraying it. All three are export-setting problems in the EDA tool, fixed by re-exporting the position data with the same origin, units and side conventions as the Gerber set — and all three are vastly cheaper to find in this viewer, with measurement to confirm a suspect position’s coordinates against the footprint it should centre on, than on an assembler’s line.

Sharing the assembly view, and the honest limits

The overlay is also a communication tool: export the pick-and-place layer over the silkscreen and copper to PNG or PDF using the picture export workflow, and you have an assembly reference an assembler or a hand-soldering colleague can actually use — positions in context, rather than a raw CSV. Keep the limit in view while doing so: Gerbv views position data; it is not assembly software. It does not manage bills of materials, generate placement programmes or check parts against a library. The sanity check described here is a visual audit by the designer, and its power is that it puts the assembler’s data in front of the designer’s eyes, in registration, before the data drives any machine.

Frequently asked questions

Which pick-and-place formats does Gerbv view?

CSV pick-and-place files — XY centroid data of the kind PCB design programs produce; the format also appears as XY and XYRS in the project’s documentation. Gerbv draws the positions as a layer over your Gerber stack.

What is the fastest way to spot a bad pick-and-place export?

Overlay it on the copper at whole-board zoom. Scale errors compress or explode the pattern, origin errors shift it as a block off the pads, and mirror errors only match the board when flipped — all three are obvious visually and nearly invisible in the raw CSV.

Can Gerbv check my bill of materials or programme a placement machine?

No. Gerbv views position data in registration with the board so you can audit it visually. It does not manage BOMs, generate placement programmes or check parts against a library.

What actually shipped in v2.13.0

The release attaches six assets on GitHub Releases, covering every supported platform:

• Windows installer: gerbv-2.13.0-win64.exe — 15,062,430 bytes — NSIS-packaged, cross-compiled from Fedora — download
• Windows portable ZIP: gerbv_v2.13.0_.Windows.MSYS2.UCRT64.zip — 17,962,489 bytes — built natively with MSYS2 — download
• macOS ZIP: gerbv_v2.13.0_.macOS.zip — 6,795,082 bytes — the first official macOS build in a release (a ZIP, not a DMG) — download
• Ubuntu 22.04 .deb: 4,267,552 bytes — download
• Debian 13 .deb: 4,263,454 bytes — download
• Fedora 43 .rpm: 2,290,118 bytes — download

Every asset carries a published SHA-256 digest in the release metadata; the full table with all six checksums is on the download page. The Windows builds are 64-bit, with Windows 10 as the tested target. The two Windows variants are the release’s signature detail: one build cross-compiled on Fedora and delivered through an NSIS installer for a conventional setup experience, and one built natively on Windows under MSYS2 and delivered as an extract-and-run ZIP for portable use — the subject of our portable build guide. The macOS build had existed in the project’s CI during the previous release cycle, but v2.13.0 is where the macOS files first became part of the public release.

Why 2026? The revival context

To see why this release matters, look at the timeline around it. Gerbv, a GPL-2.0-or-later viewer for Gerber RS-274X, Excellon drill and CSV pick-and-place files from the gEDA project family, had been quiet for a long time: v2.10.0 shipped in August 2023, and then no new release appeared for roughly two and a half years. The project was not formally abandoned, but from the outside it looked dormant. Then, in three weeks in early 2026, four stable releases landed. v2.11.0 (February 28, 2026) was the first release after a rewrite of the build system to CMake, and it already restructured distribution: a .deb for Debian and Ubuntu, an .rpm for Red Hat/Fedora, and a .zip for Windows. v2.11.1 (March 2) followed as a quick stabilisation release. v2.12.0 (March 8) then delivered functional news: DXF export became built in on all platforms (previously it depended on how the build was configured), and a new optimised SVG export arrived with optional Inkscape layers. v2.13.0 capped the sequence by completing the platform story with the native Windows and macOS release builds. The full chronology, including the SourceForge era, is in our version history.

What did not change

Just as important for existing users: v2.13.0 is the same Gerbv underneath. The interface still runs on GTK 2 with Cairo rendering — the GTK 3 port remains on the maintainer’s plan, not in this release. The format story is unchanged: RS-274X is the core format, Excellon drill and CSV pick-and-place files are supported, and legacy RS-274D is explicitly not supported. It remains a 2D viewer with layer stacking, transparency, measurement and report windows — not a PCB editor, with no 3D view and no design-rule or DFM checking. Export covers PNG, PDF, PS, SVG, RS-274X, drill formats and DXF. Saying this plainly matters: the 2026 releases modernised how Gerbv is built and distributed, and added real export improvements in 2.12.0, but they did not turn it into a different kind of tool.

For builders: the CMake foundation underneath

The platform story was possible because of the build-system work that landed first. Since the CMake transition, Gerbv builds with CMake presets and the Ninja build tool; the project’s BUILD.md documents presets including linux-gnu-gcc, macos-clang, mingw-w64-gcc and msys2-ucrt64-gcc — a list that maps almost one-to-one onto the six release assets above. The README’s build requirements are correspondingly concrete: a C compiler, the gtk+-2.0 and glib-2.0 development packages, CMake 3.28 or newer, and Ninja. Most users should never need any of this — the release binaries exist precisely so that viewing a Gerber file does not start with a compile — but the preset list is the clearest evidence that native Windows and macOS output in 2.13.0 is a designed feature of the new build system, not a one-off experiment.

Getting v2.13.0

All six assets are on the official GitHub release, and this site’s download page links each one through its /go/ shortcut with sizes and SHA-256 checksums for verification. Platform guides walk through the details: installing on Windows (including SmartScreen and checksum verification), installing on macOS (the ZIP, Gatekeeper, and the Homebrew option — brew install gerbv, which tracks 2.13.0), and installing on Linux with the .deb and .rpm packages. Activity has continued since the release — the project’s CI binaries were rebuilt in August 2026 — so “revived and between releases” is the fair summary of where Gerbv stands.

Frequently asked questions

When was Gerbv 2.13.0 released?

March 20, 2026. It is the latest stable release, following v2.12.0 (March 8, 2026), v2.11.1 (March 2, 2026) and v2.11.0 (February 28, 2026) in the project’s 2026 revival.

What is new in Gerbv 2.13.0?

The first native Windows and macOS builds in a public release: an NSIS-packaged Windows installer, a native MSYS2 Windows ZIP, and an official macOS ZIP, alongside the Ubuntu/Debian .deb and Fedora .rpm packages.

Is there a macOS DMG or a 32-bit Windows build in 2.13.0?

No. The macOS artifact is a .zip, and both Windows builds are 64-bit only. Windows 7 remains supported only up to Gerbv 2.8.0.

Cairo: the renderer underneath the view

Gerbv draws its board view with Cairo, the 2D graphics library that also powers its exported images — the picture exports to PNG, PDF, PS and SVG exist because of Cairo, and command-line image export is documented as a Cairo path. That shared rendering is worth understanding: the transparency you set up in the viewer, the antialiasing that keeps fine traces readable at odd zoom levels (the command-line export documents an antialias option), and the colours you assign are not a screen approximation of the board — they are the same rendering that produces the documentation you export in exporting to PDF, PNG or SVG. Historically there was also a GDK drawing path, described as the legacy, faster frontend; the project’s direction has been to retire it in favour of Cairo as part of a longer-term GTK port plan, and Cairo is the renderer current releases are built around. For inspection purposes, the practical translation is: learn to drive the one renderer well, and both your screen checks and your exported records improve together.

What transparency changes about a stack

At full opacity, a stack shows you the top layer and hides the rest; transparency lets each layer be drawn see-through, so overlapping geometry from several layers is visible in one view, with colours blending where features coincide. That single change converts several checks from memory exercises into direct observations. A solder mask layer drawn transparently over its copper shows at a glance whether each mask opening is centred on the pad it exposes — offset openings announce themselves as crescents. A transparent drill layer over copper, the overlay from viewing Excellon drill files, shows concentricity everywhere at once instead of hit by hit. Silkscreen over mask and copper shows whether ink stays on mask or strays across pads. And two copper layers drawn transparently together reveal the relationship between a via and the features it passes on the other side. In each case the fault class is the same — a spatial relationship between layers that no single-layer view contains — and transparency is what makes that relationship visible.

Working a stack systematically with transparency

Transparency rewards method, because a fully transparent six-layer stack can be as confusing as an opaque one. Work in deliberate pairs and triples, in the physical order of the board. Start with one copper layer and its own solder mask: assign them distinct colours from the layer list — right-clicking a layer offers per-layer operations including changing its colour — set the mask see-through, and scan pad by pad class: connectors first, then ICs, then discretes. Add the silkscreen for that side and repeat the pass looking only at ink-versus-pad relationships. Then switch sides and do the same for the bottom pair. Bring the drill layer in transparently over each copper layer in turn for the registration pass. Only at the end, if you want the record image, assemble the full stack transparently and export it; the full composite is a fine summary picture, but the pairwise passes are where faults are actually found. Zoom discipline matters as much as layer discipline: at whole-board zoom, transparency checks orientation and gross alignment; the crescent mask openings and half-landing vias only exist at magnifications where pads are centimetres wide on screen, which ties this technique to the habits in measuring distances and clearances — see it transparently, then measure it to be sure.

Colour choices are part of the technique

Because transparent layers blend, colour stops being decoration and becomes encoding. Give each layer family a consistent hue across every board you inspect — copper one family, mask another, drills a high-contrast accent — so a blended overlap colour means the same thing in every session: when mask-over-copper always produces the same combined tone, a pad whose tone differs stands out before you consciously analyse it. Avoid assigning two layers colours that blend into a third layer’s colour, and avoid red-green pairings as the sole distinction between two layers, for the usual readability reasons. None of this requires any feature beyond the documented layer operations — visibility, colour change, reload — plus the transparency mode itself; the technique is in the workflow, not in exotic settings.

Limits: transparency shows, it does not judge

End with the honest boundary, as with every Gerbv capability. Transparency and Cairo rendering show relationships with great clarity, but Gerbv does not evaluate them: there is no design-rule or DFM checking in the program, no automatic flag that a mask opening is undersized or a clearance too tight — the report windows summarise codes and apertures, and the judging remains yours. A transparent view can also mislead the hurried: a blend that looks like overlap can be two features at different depths that never interact physically, which is why the pairwise, board-order discipline above matters. Used that way — renderer understood, pairs checked in order, colours encoding layer families, suspicions confirmed by measurement — transparency is the closest thing a 2D viewer has to holding the board up to the light, and it is the technique this site’s other tutorials keep pointing back to.

Frequently asked questions

What does transparency mode actually do in Gerbv?

It draws layers see-through using the Cairo renderer, so geometry from layers underneath remains visible through the layers above. That makes between-layer relationships — mask openings over pads, drills over copper, ink over mask — directly visible instead of inferred.

Is the Cairo rendering the same as what gets exported?

Yes — Cairo is also the rendering behind Gerbv’s image exports to PNG, PDF, PS and SVG, and command-line image export is a documented Cairo path. The colours, transparency and antialiasing you set up for inspection carry into exported documentation.

Can transparency find shorts and errors automatically?

No. Transparency makes potential problems visible to you; Gerbv has no design-rule or DFM checking and flags nothing automatically. Confirm anything suspicious with the measure tool and your own checklist.

Two Windows builds, two build systems

The v2.13.0 release notes describe the pair plainly: the project now makes two Windows variants. One is cross-compiled on Fedora and packaged with the NSIS installer — that is gerbv-2.13.0-win64.exe, the build covered in our Windows installation guide. The other is built natively on Windows with MSYS2, using the UCRT64 toolchain, and shipped as a plain ZIP archive. MSYS2 is a Windows software-building environment, and UCRT64 refers to its build profile targeting the Universal C Runtime on 64-bit Windows. The practical consequence of the ZIP packaging is what matters here: no setup wizard, no registry-driven install step, no uninstaller — just a folder of files that includes the gerbv executable and the libraries it needs.

The file: name, size and checksum

The portable build’s asset name is long but exact: gerbv_v2.13.0_.Windows.MSYS2.UCRT64.zip, at 17,962,489 bytes (about 18 MB — slightly larger than the 15 MB installer, which is typical for a self-contained folder). Download it via /go/gerbv-win-zip, which redirects to the official v2.13.0 asset on GitHub Releases. Before extracting anything, verify the archive in PowerShell:

Get-FileHash .\gerbv_v2.13.0_.Windows.MSYS2.UCRT64.zip -Algorithm SHA256

The result must match the published SHA-256:

bb77865da031df83482196a6f6e9fa98298433979d995c068c4533b9b5a9ee7d

If it does not match, delete the file and download it again from the official release. Verifying matters doubly for a portable build, because a folder that can be copied anywhere can also be copied from anywhere — the checksum is how you know your copy is the project’s build and not a repackaged one.

Extract and run

Right-click the ZIP and choose Extract All (or use your archiver of choice), putting the folder somewhere you can write to — your Documents folder, a tools folder on a second drive, or a USB stick. Then open the extracted folder and run the gerbv executable inside it. That is the whole setup. Gerbv opens with its layer list ready: load your Gerber RS-274X layers, Excellon drill file and CSV pick-and-place file from the File menu, and you are viewing the board. When you are done, closing the program leaves nothing running, and deleting the folder removes the “installation” completely.

One expectation to set: because the ZIP bypasses the installer, Windows SmartScreen may comment on the unsigned executable the first time you run it, just as it can with the installer. The checksum verification above is the step that lets you treat that prompt sensibly — as general guidance, with a verified file you can choose More info, then Run anyway. Both Windows builds are 64-bit and Windows 10 is the tested platform; on Windows 7, neither v2.13.0 build applies — upstream supports Windows 7 only up to v2.8.0, as the version history explains.

When portable beats the installer (and when it doesn’t)

Choose the ZIP build when you cannot install software (no administrator rights, a managed work PC), when you want Gerbv on a USB stick for the lab bench or a client visit, when you are evaluating the program and want a zero-commitment trial, or when you want two side-by-side copies — for example the release build and a fresh download — without them interfering. Choose the NSIS installer for your own main machine: it integrates with the Start menu, associates itself properly in the system, and can be removed through Windows’ normal app management. Feature-wise there is nothing to choose between them: same viewer, same RS-274X/Excellon/CSV support, same layer tools, measurement and report windows, same PNG/PDF/PS/SVG/DXF export, and the same honest limits — 2D only, no RS-274D, no design-rule checking.

Keeping a portable copy current

A portable folder does not update itself, so staying current is a manual habit: when a new release appears, download the new ZIP, verify its checksum, extract it to a fresh folder, and delete the old one once you are happy. The project’s pace makes this easy to follow — after years of quiet it shipped four releases in three weeks in early 2026, a story told in Gerbv 2.13.0: first native Windows and macOS builds. If you later move to a machine where installing is fine, the step-by-step installer guide covers the NSIS route, and the download page keeps every platform’s file, size and SHA-256 in one table.

Frequently asked questions

Is the Gerbv ZIP build really portable — no installation at all?

Yes. The MSYS2 UCRT64 ZIP from the official v2.13.0 release extracts to a self-contained folder; you run the executable from there, including from a USB stick, and deleting the folder removes it.

What is the difference between the ZIP and the .exe installer?

The .exe is an NSIS installer cross-compiled from Fedora that installs Gerbv system-wide with shortcuts and an uninstaller. The ZIP is built natively with MSYS2 and needs no install. The viewer itself is the same.

How do I verify the portable download?

Run Get-FileHash on the ZIP in PowerShell and compare it with the published SHA-256 bb77865da031df83482196a6f6e9fa98298433979d995c068c4533b9b5a9ee7d (17,962,489 bytes). Only extract and run it if they match exactly.

The 3-2-1 principle, in plain terms

The 3-2-1 rule is a rule of thumb for keeping data safe: keep three copies of anything important, stored on two different kinds of media or locations, with one copy kept off-site — somewhere a single theft, fire or flood at your desk cannot reach. Makers do not need enterprise tooling to follow it. In practice it usually means: the working copy on your computer, a second copy on a separate drive or home storage, and a third copy in cloud storage. Each layer protects against a different failure — accidental deletion, a dead drive, and losing the building, respectively — and the system only works if making the copies is habitual rather than heroic.

What to keep from every PCB project

Back up the project, not just the design file. A complete, restorable PCB project archive contains: the CAD project sources — schematic, board layout and any local libraries or footprints you created, since a layout without its custom library parts may not open cleanly elsewhere; the exported fabrication set exactly as sent to the fab — Gerber layers, the Excellon drill file and, for assembly, the pick-and-place file; the bill of materials and your sourcing notes, including any substitutions you made during the build; and a short build note recording what the board is, which revision it represents, and anything you would tell your future self — a jumper you always fit, a part that ran hot, the bodge you applied to the first batch. That note is the file most people skip and most wish they had.

Version the exports, not just the sources

Sources evolve continuously, but fabs receive snapshots. Keep each released fabrication set in its own clearly named folder alongside the sources at that moment, so the Gerbers on your disk always answer the question: what exactly did the fab build? This discipline pays off the first time a delivered board misbehaves — you can open the precise Gerber set that produced it in Gerbv, using the opening guide, and check the physical board against the exact data it was made from, rather than against a design that has since been edited three times. It also protects you socially: when you share files with a collaborator or a fab’s support desk, everyone inspects the same snapshot.

A folder habit that survives enthusiasm

Backup systems fail socially before they fail technically. Keep the structure boring and identical for every project: one project folder, with sources at the top level and dated release folders beneath it, each holding the Gerbers, drill and assembly files for that revision plus the BOM and build note. Boring is the point — a structure you can reproduce half-asleep after a long build session is one you will actually maintain. Whatever CAD tool you use, from the workflows covered in our KiCad checking guide to the other export guides on this site, the archive shape stays the same.

The cloud copy, and one honest option

The off-site copy is the layer makers most often postpone, because it needs a decision. Any reputable cloud storage you already use satisfies the principle; what matters is that the project archive lands there automatically or by a routine you trust, not that it uses a particular brand. If you are choosing a service for this role, you can look at pCloud — that is an affiliate link, and purchases through it may earn this site a commission at no extra cost to you, as set out on our Affiliate Disclosure page. Judge any cloud option, including that one, by the same plain criteria: does it sync or accept uploads the way you work, can you restore a whole project folder easily, and will you still be using it in three years? A backup you abandon is not a backup.

Test the restore before you need it

A backup that has never been restored is a hope, not a system. Once per project — and at least once while setting your system up — perform a trial restore: copy the archive to a spare folder or a different machine, open the sources, and load the released Gerber set in the viewer from the download page. Confirm the drill file overlays the copper, the BOM opens, and the build note makes sense to you cold. The test takes minutes and catches the classic silent failures: the library that never got copied, the export folder that was empty, the cloud folder that synced everything except the one subdirectory that mattered.

What this system deliberately leaves out

This is a maker’s system, not an IT department’s. It does not prescribe backup software, schedules measured in hours, or retention policies — for design files that change when you work on them, a copy made at every release and at every work session’s end, in three places, is a proportionate defence. If your boards become a business, graduate the system then; the archive structure above scales with you, because the habit — complete project, versioned exports, one off-site copy, tested restores — is the same at every scale. Start it with your current project, before the story at the top of this guide becomes yours.

Frequently asked questions

What does the 3-2-1 backup rule mean for PCB files?

Keep three copies of each project archive, on two different kinds of storage, with one copy off-site — typically your working computer, a separate local drive, and a cloud copy. Each layer guards against a different loss: deletion, drive failure, and losing everything at one location.

Which files belong in a PCB project backup?

The complete project: CAD sources with any custom libraries, the exact Gerber, drill and pick-and-place sets sent to the fab for each revision, the BOM with sourcing notes and substitutions, and a short build note describing the revision and anything future-you needs to know.

Why keep old Gerber exports if I have the design sources?

Because the fab built a snapshot, not your current sources. Keeping each released Gerber set lets you compare a delivered board against the exact data it was made from, reproduce an order precisely, and debug discrepancies without guessing which edits came later.

Why drills live in their own file

The split is historical and practical. Drilling is a mechanical operation done by a different machine from the photoplotters Gerber was written for, and its data needs are different: not shapes, but diameters and positions. So while a Gerber layer says “draw this”, the Excellon file says “with tool such-and-such, drill here, here and here”. The fab reads your copper layers from the Gerbers and your holes from the drill file, and the two must agree — in units, in origin and in scale — because they were almost certainly exported in two separate steps of the same CAD session.

Anatomy: the tool table and the hole list

An Excellon file has two parts. First comes a tool table: a numbered list of tools, each with a diameter — T1 might be a small via drill, T2 a mounting-hole drill, and so on. The number of tools and their sizes are the design’s complete hole inventory in miniature. Then comes the body: blocks of coordinates grouped by tool, meaning “every coordinate in this block is drilled with this tool, at this diameter”. Open the file as text and you can read both parts directly — it is one of the most human-legible files in the package, and glancing at the tool table is a fast sanity check: if a diameter you expect is absent, or an absurd one is present, the export deserves a second look before it goes anywhere.

How drill data meets the Gerber layers

On their own, coordinates are just numbers. They become holes in your board only when the drill file is overlaid on the copper layers with matching units and a shared origin — which is why the standard check is visual and comparative. Load the drill file together with the top copper in a viewer and the truth is immediate: holes sit centred on their pads, or they visibly do not. Gerbv views Excellon drill files alongside Gerber layers for exactly this purpose; get it from the download page and follow the checking flow in drill holes the wrong size or offset when something looks off. The viewer also reports drill-code statistics, so the tool inventory in the file can be compared against the design’s expectations.

Why scale and offset errors happen

Drill files fail in families. Size errors usually trace back to the tool table or to units: a diameter interpreted in the wrong unit becomes a hole wildly too big or too small, even though every position is right. Position errors come in two shapes. A uniform offset — every hole shifted by the same amount — points to an origin mismatch between the drill export and the Gerber export. A scale pattern — holes that register at one corner and drift further out of place across the board — points to a format mismatch: drills written with a different number format or zero-suppression convention than the reader assumes, so coordinates are stretched rather than shifted. The diagnostic habit is to separate the two questions early: are the diameters right (a tool-table question) and are the positions right (a units/origin/format question)? Each has a different fix, and both fixes belong in the CAD export settings, not in the viewer.

The 60-second drill check

Before any order: open the drill file’s text and eyeball the tool table against your design’s hole sizes. Then overlay the drill file on the copper in Gerbv, zoom to a corner and to a mounting hole, and measure one known hole or one known board dimension. If sizes, positions and one measurement agree, the file is doing its job. The general context — how drill data fits the rest of the package — is covered in what is a Gerber file and the Gerber viewer hub, and the tools for this check are compared in the best free Gerber viewers roundup.

Frequently asked questions

Is an Excellon file a Gerber file?

No. Gerber files describe printed layers as images; an Excellon file is a separate drill program with a tool table of diameters and coordinate lists per tool. Gerbv views both, stacked together, so holes can be checked against the copper pads they belong to.

What is the tool table in a drill file?

It is the header list that assigns each tool number a diameter. The body of the file then gives coordinates per tool. Reading the tool table is a quick audit: every hole size in your design should appear there, and no unexpected diameter should.

Why are my drill holes scaled wrong when the Gerbers are fine?

Because the two were exported separately. A unit, origin or number-format mismatch in the drill export alone produces shifted or stretched holes while the Gerber layers stay correct. Diagnose size and position separately, then fix the drill export settings in your CAD tool.