Blocks are a concept unique to DatoCMS and are the foundation behind powerful flagship features such as Modular Content and Structured Text, which we advise you to read about in detail.

In a sentence, though, blocks allow you to define complex and repeatable structures that can be embedded inside records. Modern web design often involves the use of repeated "graphic components" across pages — call-to-actions, sliders, testimonial quotes, etc. Blocks allow developers to clearly represent each of these objects, so that they can then be used and reused in the content of individual pages by marketers and content creators, giving them significant expressive freedom.

You can manage your Blocks Library inside the settings area of your project:

What can you with Blocks?

You can use blocks in two different contexts, to achieve different results:

Using Structured Text fields, you can produce great pieces of content by interleaving free-form text with blocks representing predefined graphic components (CTA, quotes, image galleries, infographics, etc).
Using Modular Content fields, you can create a page-builder to let your editors combine different blocks together like Lego pieces to build any kind of dynamic layout (especially useful for landing-pages).

Key concepts

Just like records, a block is a composition of fields, on which you can define custom validations;
Blocks defined in the library can be reused across different models;
Unlike records, blocks do not exist independently, but only within a parent record. For this reason, blocks do not count towards your plan's records limit, and cannot be referenced in Link fields. They only live inside Modular Content and Structured Text fields.
When a record gets deleted, all the blocks it contains are deleted with it. This leaves no orphan data structures lying around your project.
Block fields per se cannot be localized. Instead, it's the containing Modular Content or Structured Text field that can be localized, so that different content/blocks can be defined for each language.

While link fields reference other records, Modular Content and Structured Text fields let you embed blocks inside the record

When to use blocks instead of models?

It's fairly easy to recognize when a piece of content should be modeled as a model or block if you ask yourself the following questions:

"Would I ever want to reference this content outside of the record in which it is defined?" — if so, then it should be a model.
"Does this content have standalone value, or does it make sense only in the context of a parent record?" — in the first case, it should be a model; otherwise it should be a block.
"If the parent record were to be deleted, do I want this content to be deleted as well, or would I like it to remain?" — in the first case, it should be a block; otherwise it is a model.