We already know what a field is.
A field is a column. A content type is the spreadsheet. A node is the row. We established this several chapters ago and it has been holding up well ever since. Gerald understands it. His wife understands it. Spike probably understands it and he was only half paying attention.
But there is one more thing about fields that is worth knowing before we go any further, because it is the thing that makes Drupal fields different from the columns in Gerald's spreadsheet.
A Drupal field knows what kind of data it holds.
This sounds like a small distinction. It isn't.
Gerald's spreadsheet has columns. The shoe size column is a column. The birthday column is a column. The notes column is a column. They are all, from the spreadsheet's point of view, mostly the same thing treated as a default — a box where you type something. The spreadsheet makes assumptions that shoe size is a number, that birthday is a date, or that notes is where Gerald puts everything he couldn't figure out where else to put. It just holds whatever you type and asks no questions. True you can assign a type value to a spreadsheet column, but...
Drupal asks questions.
When you add a field to a content type, Drupal wants to know what kind of field it is. A date field holds a date — and because it knows it's a date, it can sort chronologically, display a calendar picker, calculate how many days until an event, and tell you every photo taken in July. A number field holds a number — and because it knows it's a number, it can sort numerically, calculate averages, and refuse to accept the word "blue" as a valid entry.
An image field holds an image. A text field holds text. A boolean field holds yes or no, and nothing else, because sometimes yes or no is the whole answer and a text field full of people typing "yes", "Yes", "YES", "yep", and "affirmative" is not a boolean field, it is a data cleanup project.
The field type is the difference between data that knows what it is and data that is just sitting in a box hoping for the best.
A quick tour of the most common field types. This is not exhaustive. Consider it an introduction at a party — first names only, more conversation later.
Text — words. Short text for titles and labels. Long text for bodies and descriptions. Formatted text when you need headings and bold and the occasional hyperlink.
Number — quantities. Integer for whole numbers. Decimal for prices and measurements. Not for zip codes. We will come back to this.
Date — moments in time. A single date, a date and time, or a date range with a start and an end. Drupal knows how to sort these, display them, and reason about them in ways a text field never could.
Image — photos, illustrations, icons. Drupal stores the file and the metadata separately, which means you can display the same image at different sizes in different contexts without uploading it twice.
Boolean — yes or no. Published or unpublished. Featured or not featured. Spike likes crab cakes or Spike does not like crab cakes, though in practice this particular boolean has never been set to no.
Entity Reference — a connection to another record. This is the field that put Spike's face on the crab cake recipe. This is the field that connects a photo to a taxonomy term, a node to a vocabulary, a recipe to a person. Entity reference is how Drupal knows that two records are related without copying data from one into the other. It is the most powerful field type on the list and it deserves its own chapter, which it will get.
Now. About zip codes.
A zip code looks like a number. It is made entirely of digits. You would be forgiven for creating a zip code field and selecting the number type, because that seems like the obvious choice and nobody warned you.
Do not do this.
A zip code is not a number. You will never add two zip codes together. You will never calculate the average zip code. You will never need to know whether 90210 is greater than 10001, and if you do need to know that the answer is yes but it will not help you. A zip code is an identifier that happens to be made of digits, which is completely different from a number, and the difference matters the moment one of your customers lives in Connecticut.
Connecticut zip codes start with zero. 06830. 06902. 06040. Store those as numbers and Drupal will helpfully remove the leading zero, because numbers don't have leading zeros, and suddenly Greenwich is in zip code 6830 which does not exist and your holiday mailing list has a problem.
Gerald has customers in Connecticut. Gerald uses a text field for zip codes. Gerald's holiday mailing list works correctly. This is not an accident.
The lesson is not that zip codes are complicated. The lesson is that choosing the right field type requires a moment of thought about what the data actually is, not just what it looks like. A field that looks like a number is not always a number. A field that looks like text is not always best stored as text. The design conversation that happens before you build includes the field type conversation, and the field type conversation occasionally includes a zip code.
Fields go deep.
Every field type has a formatter — the decision about how the data is displayed on the page. A date field can display as "April 16, 2026" or "04/16/26" or "3 days from now" depending on the formatter you choose. The data doesn't change. The presentation does.
Every field type has a widget — the interface the editor uses to enter the data. A boolean field can be a checkbox or a toggle or a dropdown. An entity reference field can be a text box with autocomplete or a dropdown list or a set of checkboxes. The data doesn't change. The editing experience does.
There are contributed field types that do things the core field types never anticipated — geolocation fields that store coordinates and display maps, color fields that store hex values and display swatches, computed fields that calculate their own value from other fields so you never have to type it.
All of that is for later chapters. For now the important thing is this: a field is not just a column. It is a column that knows what it is, refuses to hold the wrong kind of data, and rewards you for choosing it carefully.
Gerald chose a text field for zip codes. Gerald's customers in Connecticut received their Christmas cards.
It was a good year.