In one 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 represent with clarity of intent each of these objects, so that they can then be used and recalled in the content of individual pages by marketers and content creators, giving them a lot of a lot of expressive freedom.
You can manage your Blocks Library inside the settings area of your project:
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).
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 live an independent life, but exist only within a parent record. For this reason, blocks do not count towards your plan records limit, and cannot be referenced in Link fields. They only live inside Modular Content and Structured Text.
When a record gets deleted, all the blocks it embeds are deleted with it. This leaves no orphan data structures laying around your project.
Block fields per se cannot be localized. 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.
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 is a model.
"Does this content have dignity of its own, or does it just make sense in the context of a parent record?" — in the first case it is a model, otherwise it is 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 is a block, otherwise it is a model.