Standard symbol field names initiative

Following discussions here on the forum, on the KiCAD libraries GitHub and the developers mailing list it seems there is no consensus on setting up default names in KiCAD or the standard symbol libraries as an acceptable solution to encouraging interoperability between third party tools.

It is therefore up to the community of tool builders to decide on a standard to follow, to prepare a document that describes it and to put it up online somewhere and badger people when they don’t use it. :slight_smile:

The following is a draft of my proposed standard. Please read it carefully and submit any comments or suggestions. Please try and avoid bikeshedding and give clear reasons for any amendments or additions.

EDIT: an alternative proposal is to keep separate fields for each of Manufacturer, MPN, Vendor and SKU as described by @bobc below. Some things to consider:

  • The colon character should not present a problem if the approved vendor and manufacturer names are used even if there is a colon in the part name
  • Seperate fields are easier to parse
  • Use : as seperator
  • Have separate fields

0 voters

KiCAD Community Standard Symbol Fields

1 Brief

Detailed are standard field names and value schemas for KiCAD symbol libraries that should be adopted as the defaults for any KiCAD tooling. This is to encourage interoperability between third party tools.

2 Existing Fields

KiCAD already hard-codes 4 fields with the following schema.

| Name      | Value                 |
| Reference | <Reference>           |
| Value     | <Value>               |
| Footprint | <Library>:<Footprint> |
| Datasheet | URL                   |

3 Additional Fields

3.1 Fields

On top of KiCAD’s hard-coded fields we add the following fields.

| Name         | Value                |
| MPN<Integer> | <Manufacturer>:<MPN> |
| SKU<Integer> | <Vendor>:<SKU>       |

3.2 Types

  1. All strings are UTF-8 encoded and exclude the colon character (:, i.e U+003A)
  2. <Integer> indicates a positive integer starting at 1
  3. <Manufacturer> should be string indicating manufacturer name as listed by Octopart
  4. <MPN> should be a string of a manufacturer’s published part number
  5. <Vendor> should be a string indicating vendor as listed by Octopart
  6. <SKU> should be a string of a retailer part number, a.k.a stock keeping unit

TBD: I will ask Octopart whether they will provide their lists in an easily parse-able format as they did with their CPL data.

4 Example

| Name      | Value                                   |
| Reference | U1                                      |
| Value     | NE555                                   |
| Footprint | KiCad/Housings_DIP.pretty:DIP-8_W7.62mm |
| Datasheet |                                         |
| MPN1      | Texas Instruments:NE555P                |
| MPN2      | Microsemi:NE555P                        |
| SKU1      | Digi-Key:296-1411-5-ND                  |
| SKU2      | Ralph's Elec.:SEMI-NE555P               |
| SKU3      | Ralph's Elec.:TEXAS-NE555P              |

5 F.A.Q

5.1 But Manufacturers change name and MPNs all the time, things go out of stock.

If a manufacturer changes name, a part goes out of production, goes out of stock or is re-stocked with a new SKU the user can simply append a new MPN or SKU pair. They can delete the old pair if they wish.

Looks basically ok.

I am a bit wary of that one for a couple of reasons. Packing two bits of data into one field causes conversion issues, e.g. if you store manufacturer and part number as two fields in a database, which will normally be the case, then you can’t do a straight query to get the data.

Second is that using magic character for a separator will inevitably go wrong, since we can’t enforce how manufacturers name their parts. There are a few parts with “:” in the name (I checked :slight_smile: ).

I would suggest something like:



Could you link those please? I have looked before…

You could argue that is so rare that it is not worth worrying about, but what about the future? Molex might introduce a range of popular connectors with “:” in, you just never know. But I have learned over the years, if I don’t control the data, I should not make assumptions about it, and when those 1 in a million events happen, it can be a real pain to fix.


Good find, but this then would be Micron Technology Inc.:MT47H64M16HR-25:H TR and is still unambiguous. I can see the reason to avoid it though. I still like one field just because it’s neater.

I have put up a poll on the main post. Put it now seems to prevent me form amending the proposal all together!

If you are suggesting that the parser must know all the manufacturer names to parse the field, that is a terrible idea and almost unworkable. It’s a recipe for bugs. Been there, done that!

No, I am suggesting it only looks for the first :. As we will publish a list of manufacturer names we can ensure they don’t contain :.

Also, the vendor thing is a bit too much. Rather just have a PartNumber since it works for House numbers and MFPN

1 Like

I think you are missing the point a bit TotalKrill, if you want to add your house part numbers just use whatever you want. They won’t be useful to anyone else.

Ok, this is looking like it’s heading down completely the wrong track already :slight_smile:

It’s one thing to have unforeseen issues with a spec, but starting out with known flaws is crazy!

It’s real easy for humans to look at data and parse it. It is a lot harder for the computer. Plus the average programmer will take one look at the spec, and use the colon and build in all sorts of bugs. If you are designing something for automated processing, it must be completely unambiguous and really easy to implement.

1 Like

I would accept that it’s a flaw if it was ambiguous but it’s not. The manufacturer name goes before the first : and cannot contain a :.

I accept that it complicates things a little. I am not married to the idea anyway, I just have my preference.

So what happens when Octopart list a manufacturer with colon in the name? It might not be likely, but it could happen. According to the spec you have written above, it is ambiguous.

I am sorry to say I think this proposal will go the same way as the other standardization attempts. Specs that rely on extra unwritten rules to work correctly are doomed.

Anyway, I’m out…have fun.

Ive been in this discussion a lot before, What everyone can agree on is that they want a part number designator field, or not. Just a field where they can add a Manufacturer number or a Partnumber.

A partnumber will be usable for everyone, since companies using a house number have somewhere a house number translator.
Having a strange formatting syntax in the field is just madness. Also following Kicads standards somewhat, we should really not start using abbreviations. PartNumber is the best compromise.

This thread have the worst example of a PartNumber field ive seen yet. Im out.

This thread is why we can’t have nice things…

1 Like

@bobc We get the initial list from Octopart and publish it. I think it’s a bit unfair to say this discussion is “heading down completely the wrong track already” and say you are “out” when I amended the proposal with your suggestion.

@TotalKrill I think what you are looking for is something else and it seems much better to me to keep these concerns separated in clearly defined fields. I’ll take your opinion regarding abbreviations into account. I was mainly going for compactness with this proposal. Please register your vote regarding the formatting in the poll.

@devbisme It is quite frustrating, haha! Would be nice to get a definite yay or nay out of you though.


  • Use abbreviated names like MPN and SKU
  • Use un-abbreviated names like “Part Number” and “Stock Keeping Unit”

0 voters

Concept/Aim seems to be to have ALL options for a part (manufacturer as well as distributor) in the KiCAD symbol libraries?
Well, do what you have to do - alone thinking about the work involved and the amount of data that needs maintenance afterwards makes me depressive.

As long as those MKU/SKU definitions aren’t hardcoded into KiCAD (and just define fields in the community libs) I have no problem with whatever you propose.

PS: I think you’re doing a disservice to the community by trying to shoehorn all that information into EEschema/the symbol libraries.
Your proposal would have way more merrit and support if you would try to create a parts library as an extra tool (anyone got any ideas for a name or even how the concept would be called?) which controls the content of the symbol and footprint libraries.
That would make sense to me and would be badly needed.

I am currently developing a tool which combines KiCad with a Firebird component database, see
MSEkicadBOM uses the VALUE, VALUE1, VALUE2 and FOOTPRINTINFO fields in order to look up the actual components and footprints in the database. Distributor part numbers and the like then can be defined independently of the schematics in the database.

This is a great idea. I will support it in my Kibom application.

Should the integer type support 0, and negative numbers as well? Other than that, I think we should just go for it. It might not be perfect but it’s still a lot better than doing nothing, and I’m sure the bugs will be shaken out over time.

1 Like

The colon as separator is as good or bad as every other character.
As nobody keeps someone from creating a manufacturer or part name containing the separator, we have to find a way to deal with it.
What about quoting the offending string? That would allow to deal with “Super:Chip:Factory”:“Part::4711”.
If the string contains the quoting char?
Mask it like “Super:Chip"Factory”, even turn Super:Duper"Chip\Factory into “Super:Duper"Chip\\Factory”.

About abbreviating names or not, I prefer them abbreviated, but it’s not an issue, as renaming a column on the BOM/spreadsheet-level is easy enough.