Gerber files are too large due to thousands of drawn features

The board house I am using replied to my upload with the subject message. They suggested that this could be from drawing plane layers with thousands of 1 mil segments. However, when I examine the Gerbers in GerbView, I don’t see segments but shapes. I’m not sure what to change so I replied back to them asking.

I’m using KiCAD v5.1.2-1.

Have you checked all the layers of your Gerbers?

Advice I’ve heard earlier is to use an gerber viewer that is not part of KiCad (gEDA seems to have a usable Gerber viewer, there are also serveral online checkers, often with PCB manufacturers.

If your boardhouse complains about too big Gerbers, while the files themselves are OK, then it’s time to switch boardhouse.

I’ve had a peek at the gerber of a pretty simple PCB (LoPower2, used as example in some threads on this forum).
The F.Cu layer is 175kB and has indeed quite a lot of items drawn on it.
If I open the 175kB file in a text editor, it has over 7025 lines, and probably more then 6500 are “Flash poins” or however it’s called in Gerbers:

But I’ve never seen this before as being a problem.

Does your board have any filled zones? I forget the exact menu item at the moment, but there is an option for representing filled zones as a zillion overlapping line segments.

Can you give an estimate of your board’s complexity? And, the sizes of the generated Gerber files? (I’d ask you to post your project files, or at least just the Gerbers, but you may not yet have privileges to post attachments.)


P.S. - I see we are in the same neck of the woods!

For example . . . . here’s a directory listing showing Gerber file sizes for a two-sided board, approx 4" x 6", moderate density, predominantly SMT. The board has several filled zones, both top and bottom side:

The silk screen layer has the largest file size, followed by the copper layers. (The " *.DRL " file is a drill map, not the CNC file.)


Thank you both for your help.

I’ve looked at all of the layers with GerbView and none seem to have any rastered zones. The board is fairly busy, 5.5" x 3", two LQFPs,8-layers. Minimum trace width is 5 mils.

Looking at the files, the front copper is 2.9MB while the other layers with zones are around 1.5MB. Some of these files have 90K lines.

I’ll see if I can view the files with another viewer.

I looked for the KiCAD feature that allows specifying fill type but apparently that is the subject of a current bug report. According to the posts I’ve read on this, polygon fill is the only supported fill mode in v5.1 which is what I’m using. There is even some disagreement on that point however.

I’ve had a look at a gerber file.
It seems that not the polygon fill is problematic, but it is the outline that is around the borders of a polygon.
Each pad inside a polygon, can easily have 17 or more small straight segments around it and a thermal relief can add anogher10 or more segments.

So, with 100 pads in your gerber that is easily 2000 segments, and 100 pads is just a small PCB.
I think this is quite normal (at least for KiCad). To me it seems there is nothing wrong with your Gerbers and it should simply not be an issue for your PCB boardhouse at all.

Was the message you got back automated or was there a human involved in looking at it? Do you have the option of uploading to another board house without finalizing a purchase to double check?

I do not have much experience with Gerber fies, but I accidentally noticed a lot of (weird?) repetition in the coordinates in a gerber file. Is this normal?

Oops: After a bit of fiddling I noticed that the file with the repeated coordinates was not made by KiCad, but by opening a KiCad.gbr file in gEDA’s Gerbv, and then saving it again. The purple coordinates all are the same text string:

For reference, it is from the file:


The original file it is copied from is:

I found it strange that the file saved by Gerbv was smaller, even though it had a large number of redundant “G01” codes.
When lining stuff up a bit, I noticed however that gEDA’s Gerbv truncates the last 2 digits of coordinates.
gEDA’s Gerbv also has alternating “D01*” and “D02” codes, while the KiCad file only has “D01”. Both files do however have almost the same number of lines.
I added 3 spaces in front of the part made by KiCad, but it’s from a different section.

gEDA’s Gerbv also saved the file in mill while KiCad used metric.

Headers of the files compared in Meld:

I have no idea if this would be worth pursueing in any way, or is just normal.

Both your line count, and overall size, are about ten times larger than the files for my project. Even if an acceptable board can be manufactured from your Gerber files, something isn’t right!


3MB does not have to be excessively big. Just compared it with a board I designed (but have not manufactured) of 100x160mm. Gerber file sizes are:

The 1.8MB bottom copper has 74000 lines.
I did a test upload of this board, and uploaded all the gerbers zipped together to Oshpark. They seem to get accepted withoug problem:

You have sharp eyes (or a lot of time on your hands!) to make those observations. “Gerbv” is my preferred Gerber viewer, but I don’t recall that I have ever saved a file from within Gerbv. Does Gerbv have options to specify the numerical precision, etc, when it saves? It’s a little disturbing that it would make ANY changes to a file.

You’ve got me curious enough to want to save a virgin KiCAD Gerber from within Gerbv and compare the differences, but tonight and tomorrow are “Cheap Date” nights and I probably won’t have a chance.


Thank you all for your kind help.

I am using the board house’s free design-for-manufacturing upload tool. This generated the automatic message. I have uploaded the zip package using their other portal and have not had any trouble yet. The problem seems to be what @paulvdh mentioned in his earlier post with respect to polygons generating many minuscule line segments around pads and vias.

I remember having seen rounded pads (used in the official library, I think) creating excessively large gerbers because of that polygon outline with segments thing, plus for some reason even rounded pad corners were made with segments. I’m not sure if it’s true in the stable 5.1 version or with the current nightly builds. If you can give the project (board file) I can test with the latest code.

My board house accepted the uploaded file set without issue but did flag that the files were too big and that I should be wondering why.

Using GerbView, I enabled an internal copper layer, turned on Show Polygons in Outline Mode image and zoomed in on a pair of vias. You can see the many line segments around each via (D19 tool). I count 25 segments for 270 degrees of the top via. I have hundreds of vias and hundreds of pads so that would be lots of segments.

FWIW this issue is solved in nightlies, zones have a parameter max error, and they will automatically adapt number of segments for arcs to not exceed that error. That way for small features like vias number of segments will go down significantly.


Looking at a recent small project, I was surprised to find the front fabrication layer is big compared to the silkscreen and as big as front copper. Text seems to be drawn with more segments

Text on all layers uses exact same font with fixed segments so that can’t be the reason.

The Fab layer has values, so far more text than the silkscreen.
Fab is the biggest file

Except one test I have not reached a gerber state with my KiCad works yet.
My 20 years old Protel fills polygons with horizontal and vertical lines (I specify 8 mils width). And gerber with such filled GND polygon of my biggest PCB (9.5x11.5cm) is 360kB size.
But in situation like this there is only one arc track around each pad.
If that function KiCad does with 25 times bigger (in file size sense) method then I would be not surprised with files of MB sizes.

Sorry, bit late to the party but I agree with what someone earler said already. Probably time to switch PCB house. I’ve had PCBs roughly the size of 44 x 28cm with thousands of components and a KiCad-PCB file size of around 14MB, Gerbers reaching up to 10MB. Shouldn’t be a problem for any company with a decent set of CAM software. I mean a textfile with 3MB and “thousands of drawn features” in 2019 shouldn’t be an issue for anyone…

1 Like