Models typically make up the foundation of most Django projects. They are the primary abstraction for managing the data/state that is the core of most "applications". Models not only define the structure of the database, each model is the mechanism for accessing and modifying the data stored in the database table represented by the model. Models are also generally responsible for any behaviors of the data and for validating data to protect the quality of the data in the database.

The most obvious part of any Django model is the list of fields. Each field in a model is related to a column or attribute in the database table associated with the model. Fields have two options that can be confusing to many developers that are new to the framework. The two options are null and blank. Although the two options might seem to address similar functionality, they are used for very different purposes.

Let's quickly review the null and blank field options.

null field option

The null field option is directly related to the definition of the corresponding column in the database. null defines whether empty (NULL) values are allowed to be stored in the database.

The default value of null=False raises IntegrityError when an empty value is attempted to be written to a non-string-based field. For string-based fields an empty string is written to the database column.

A value of null=True allows an empty value to be written as NULL to the database column. In this case Django still uses an empty string when writing an empty value to string-based field, Django does not use NULL for these field types.

blank field option

Unlike the null field option, the blank field option is unrelated to the data stored in the database. blank is used solely for form validation of the field.

The default value of blank=False causes form validation to fail when the field has an empty value. This behavior is identical for string-based and non-string-based fields.

A value of blank=True allows form validation to succeed even when the field has an empty value. This behavior is also identical for string-based and non-string-based fields.

Guidelines for usage

Now that I have given a quick overview of the null and blank field options I can proceed to recommendations on their usage.

Field Type	null=True	blank=True
Boolean fields BooleanField	Don't try this. Use NullBooleanField.	Don't try this. Use NullBooleanField.
String-based fields CharField CommaSeparatedIntegerField EmailField FileField FilePathField ImageField SlugField TextField URLField UUIDField	NO, rely on Django's conventions for empty string values.	OK if you want the corresponding form widget to accept empty values.
Numeric fields BigIntegerField DecimalField DurationField FloatField IntegerField ositiveIntegerField PositiveSmallIntegerField SmallIntegerField	OK if you want to allow NULL database values. You most likely also want blank=True.	OK if you want the corresponding form widget to accept empty values. You most likely also want null=True.
Date/Time fields DateField DateTimeField TimeField	OK if you want to allow NULL database values. You most likely also want blank=True.	OK if you want the corresponding form widget to accept empty values. You most likely also want null=True.
Relationship fields ForeignKey ManyToManyField OneToOneField	OK if you want to allow NULL database values. You most likely also want blank=True.	OK if you want the corresponding form widget to accept empty values. You most likely also want null=True.
Miscellaneous fields BinaryField GenericIPAddressField	OK if you want to allow NULL database values. You most likely also want blank=True.	OK if you want the corresponding form widget to accept empty values. You most likely also want null=True.

Hopefully these guidelines help direct you in the proper direction if you are unsure of the proper usage of these two field options.