If you spend any time on hardware repositories on GitHub, you’ve probably done this dance more times than you’d like. Find a project that looks interesting. Open the gerbers folder. Stare at a list of files with extensions like .gtl, .gbl, .gko, .drd, and realize there is no way to know what the board actually looks like without downloading the whole thing, unzipping it somewhere, and opening a separate viewer.
It is a strange friction to live with. GitHub renders Markdown. It renders Jupyter notebooks. It renders STL files in 3D. It will preview a CSV as a sortable table. But click on a Gerber file, the format that drives the entire PCB fabrication industry, and you get a page full of cryptic ASCII coordinates.
I built a Chrome extension to fix that. It is called Gerber Viewer for GitHub, and it does what the name suggests. Open any Gerber, drill, ZIP archive, or KiCad PCB file in a public or private GitHub repository, and a preview panel appears at the top of the page with the rendered board. Open a folder full of Gerber files and it does the same thing, building realistic top and bottom composite views with copper, soldermask, silkscreen, and drill holes.
It is the kind of utility that should have existed five years ago, and maybe it did exist as a janky bookmarklet on some long-dead forum thread. I checked. I could not find anything that worked on modern GitHub, handled the full range of layer naming conventions, and respected the privacy expectations of someone browsing a hardware repo.
So I wrote one.
What it actually does
The short version is “PCB previews on GitHub, no downloads, no leaving the page.” The longer version covers a few specific use cases that show up constantly in hardware work.
When you click on an individual Gerber file in a blob view, the panel renders that single layer immediately so you can see what you’re looking at. Then, while you read the file or scroll, it quietly fetches the sibling files in the same folder and builds a multi-layer composite. You end up with a Layer tab (the file you clicked), a Top tab, and a Bottom tab. For boards with inner copper layers, In1, In2, and so on appear between Top and Bottom.
When you browse a folder containing a recognizable layer set, you do not need to open any individual file first. The panel just appears and renders the composite. This matters more than you might expect: most of the time when I’m exploring a repo, I’m orienting myself by the folder structure, not by clicking into specific files.
When you encounter a ZIP archive committed to the repo (a common pattern for projects that don’t want to commit individual layer files), the extension downloads the archive, extracts it entirely in the browser using fflate, finds the Gerber files inside, and builds the same multi-layer preview. Nothing touches a server.
For KiCad .kicad_pcb files, the extension embeds KiCanvas, which is a real KiCad board viewer with proper layer toggles. That covers the modern KiCad ecosystem where boards are often shared as the native source file rather than exported Gerbers.
There is a measurement tool. You click two or more points and it tells you the distance in millimeters or mils, with running totals if you keep clicking. Useful for “wait, is that pad spacing what I think it is” and “how long is that trace, roughly.” It reads the physical-unit calibration out of the Gerber file’s own width and height attributes, so the numbers are real numbers, not approximations.
There are the things you would expect: zoom, pan, rotate, an outline toggle for boards whose edge-cuts file is messy, an invert button for dark mode, and an SVG download if you want to grab the rendered view for a slide deck or design review.
The thing I had to relearn about Gerber files
If you have not stared at Gerber files in a while, here is the part that keeps tripping people up.
Filename conventions are not standardized. KiCad calls the top copper layer “F_Cu” and writes it to “board-F_Cu.gbr”. Eagle calls it the “component side” and writes it to “.cmp”. Altium uses “.gtl”. One project might commit drill files as “.drd”; another might use “.drl” or “.txt”. The Gerber format itself does not care, but every viewer has to guess what each file is for.
Modern Gerbers solve this by declaring their role inside the file with X2 and X3 attributes. A line like %TF.FileFunction,Copper,L1,Top,Signal*% says, unambiguously, “I am the top copper layer.” But not every EDA tool emits these, and plenty of older projects on GitHub do not have them.
The extension uses both approaches: it parses X2 and X3 attributes when they exist (and shows the result in the header, so you see “Top copper (L1) • KiCad 7.0.5” instead of “arduino-uno.cmp”), and it falls back to filename-based detection through the tracespace toolkit’s whats-that-gerber library otherwise. The two approaches catch different classes of files. Together they catch almost everything.
There is also a content-sniff fallback for the cases where neither works. The Excellon drill format starts with a recognizable M48 header. The extension looks for it, regardless of what the filename says. This came out of debugging a real board where Eagle had written drill data to a .drd file that whats-that-gerber misclassified as an outline file. The top-side render was missing all the drill holes and had triangular artifacts where pcb-stackup was confused by what it thought were extra outline segments. The content-sniff fix made the bug go away unconditionally, across every EDA tool’s quirks.
Why I cared enough to ship it
The honest answer is that I spend a lot of my time both as a maker and as a working engineer looking at other people’s hardware designs. Sometimes that’s for a project I’m evaluating, sometimes for a design review, sometimes just because someone on Hackaday or in a Discord linked something cool. Every single time, the workflow was: download, unzip, open KiCad or a viewer, navigate to the file, finally see the thing.
I would estimate I have done this several thousand times in the last decade. At some point during the last project, I caught myself doing it again and just stopped. The friction was small but constant, and the small constant frictions are the ones that quietly distort what you end up looking at. You stop browsing widely. You only download projects when you’re already pretty sure you want to look at them in detail. That is the opposite of what GitHub is good for.
The extension takes a category of file that the format spec describes as “the de facto standard for transferring PCB designs” and treats it like the other formats GitHub already handles natively. That’s it. That’s the whole pitch.
What’s under the hood
For anyone curious about the technical stack: the rendering is powered by the tracespace v4 toolkit (gerber-to-svg, pcb-stackup, whats-that-gerber). This is the same library set that powers some of the major online PCB review services. It produces SVG output, which means everything renders crisply at any zoom level and the download-SVG button gives you something you can drop into a vector editor.
The ZIP support uses fflate, which is a small synchronous deflate library. I originally reached for JSZip but ran into a deadlock with one of Node’s stream polyfills when I tried to test it under jsdom. Swapping in fflate was a one-evening fix and saved roughly 100KB in the bundle.
The KiCad support uses KiCanvas, which is Thea Flowers’ open-source KiCad web viewer. KiCanvas is shipped as a web component, and there is a small gotcha worth mentioning: a Chrome extension’s content script runs in an isolated world that cannot register custom elements in the main page DOM. The fix is to inject KiCanvas as a regular script tag pointing at a file packaged inside the extension, then signal back via a shared DOM attribute. The cross-world communication problem took longer to figure out than it should have. If you ever build something similar, save yourself an hour.
Everything is bundled together with esbuild into a single content script. No remote code execution, no third-party CDNs, no telemetry, no authentication, no analytics. The only network calls the extension makes are to raw.githubusercontent.com (to fetch the files you’re looking at) and api.github.com (to list folder contents). That is the entire network footprint.
Where to get it
The extension is on the Chrome Web Store.
The source is on GitHub, GPL-3.0 licensed. If you want to read the code, file a bug, or contribute, the repository link is in the footer.
If you do install it, I would love to hear what works and what doesn’t, especially on weird old boards, unusual EDA tool outputs, and any layer naming convention I might not have seen yet. There is a lot of variety out there, and I’d rather find the rough edges through users than have nobody find them at all.
Made in the Green Shoe Garage with a lot of coffee and an unreasonable amount of caring about how PCB design files render on web pages.