2 followers Follow

How many Custom Fields can I add?

Frank Hagan

The field editor says I cannot create any more custom fields. Can I buy more? What can I do?


Official comment


In cases where the Field Editor has warned about data limits, you can convert your text fields to long text. Because the long text field can hold at least 20,000 characters you will not lose data by changing the field type. The long text field is a pointer to an external record with the text in it, saving space in the database. Because the data is fetched from another database there is a performance penalty, and we don't recommend trying to add hundreds of long text records to your database.

You can convert a text field to long text by simply editing the field. Note that you cannot convert the field back to a regular text field and a long text field cannot be used as a column heading in a list view.

image description

As an alternative, you can have Support submit a ticket to convert all your custom text fields to long text.

ONTRAPORT can also trim fields, shortening the 256 character limit in text fields to a shorter length, such as 150 characters. Note that data in these fields are truncated at the trimmed point, losing the data after that point in the field.

There is a bit more in our Knowledge Base article at

Frank Hagan

Please sign in to leave a comment.



Hey Frank! While that answer shed some light on AN issue, it doesn't really answer the actual question. For some reason, I feel I've seen that you can only add 200 custom fields into your account (regardless if it's a short or long text field). 

Is that true? 
What happens if you need more? 
How can you tell how many custom fields are being used? 

I, myself, want to add a custom tracking section that will utilize a ton of custom fields, and I feel that I will be approaching this limit, if it is indeed an actual limit, and don't want to start into that process if it's true that I won't be able to finish. 

Joe Kalis 0 votes

We used to say "200 fields" as a rule of thumb. I don't think we say that any longer, and the article linked is the real, technical limitation. 

Each Contact record is allotted 65,535 bytes of data or up to 4,096 fields. After default fields are taken into account, you end up with about 39,000 bytes of data or up to 4,000 fields left. Usually the byte limit comes into play. Each type of field you add will use reserve a fixed number of bytes as follows:

  • Checkbox: 1
  • Date: 20
  • List Selection: 20 * Number of items in list
  • Long text: 8
  • Numeric: 20
  • Price: 64
  • Phone: 768
  • State: 768
  • Dropdown: 20 * Number of items in list
  • Text: 768
  • Email: 768
  • SMS: 768
  • Address: 768

If you added only checkbox fields you would hit the 4,000 fields limit. If you add text fields, at 768 bytes, you'll get about 51. If you add date or numeric fields you might get up to 1,950. Or 609 price fields. "You can add about 200" is a pretty good compromise rule of thumb. But we had to stop using that easy answer because some people would use text fields and not get close to 200.

There might be other overhead and reserved items that have been added since that article, so the count could be off now. 

You can free up more space (bytes) by converting text fields (768 bytes) to long text fields (8 bytes) as the article explains. Long text is stored in another database, and the "pointer" to that database only requires 8 bytes. Two caveats: long text fields cannot be column headings and displaying them in the Contact Record does require more time (although that is usually not noticeable). 

Support can tell you how many custom fields you use. We have a counter in our Admin app. Your account has 104.

For your use case, I would look into using Custom Objects (CO), as each CO will have most of that 65,535 bytes available for each record. Using a one-to-many relationship between Contacts and your new CO "Tracking" database would give you unlimited CO records for each Contact. It will also prevent slowing down page rendering when you are looking at Contacts. 

Frank Hagan 0 votes