Components and Sections are the building blocks that editors and developers use to assemble storefront pages through the CMS. Understanding the difference between them is key to deciding what to create when you want to expose new content for editing in the VTEX Admin and where it should live in your project.

This guide explains both concepts, shows how they relate to Content Types, and lists common Section examples shipped with FastStore.

In the CMS, content is organized hierarchically: a Content Type specifies which Sections are available on a page, and each Section consists of one or more Components (groups of fields).

At runtime, your storefront (FastStore or another headless storefront) maps this hierarchy, Content Types, Sections, and Components, into actual UI components and HTML.

A Component is a group of fields declared with JSON Schema. It defines the data structure, such as a title, an image, or a link, that editors complete in the CMS Admin form.

Regardless of the storefront technology you use, a Component:

• Declares which fields exist and their data types.
• Controls how fields appear in the Admin (labels, descriptions, validation).
• Can be reused across different sections and content types.

Each component resides in its own .jsonc file, named following the convention cms_component__ComponentName.jsonc. The schema relies on a few CMS-specific keywords:

For more details on schema declarations, see Understanding CMS architecture and schema declarations.

The schema below defines a reusable Link Component with two fields (text and url) in a FastStore project.

A plain component can't be placed directly on a page. It's designed for reuse inside a section or as a field nested within another component.

A section is a type of component that functions as a dynamic container for other components. Sections are the units that editors drag, reorder, and configure on a page in the CMS Admin. They group other components to create specific parts of a storefront page, such as a hero banner, a product shelf, or a call-to-action block.

Conceptually, a section:

• Uses the same JSON Schema mechanics as a regular component.
• Is referenced from a content type, so it becomes available in the page editor.
• Encapsulates a part of the page (for example, "Hero", "Footer", "Product shelf").

How a section is rendered depends on the storefront:

• In FastStore projects, each section corresponds to a React component located in src/components/. These components are exported via src/components/index.tsx to render the data that editors configure in the Admin.
• In other headless storefronts, you can map section identifiers (for example, $componentKey: "Hero") to your own Vue, React, or server-side templates, following the same principle.

The schema below declares a CallToAction section in a FastStore project, composed of a title field and a nested link object, which mirrors the Link component shape:

A content type, such as home, pdp, plp, or landingPage, defines a page structure and declares which sections editors can add to that page. When you create a new section, you make it available to editors by referencing it from one or more content type schemas.

In any storefront integration:

• Components and sections define what can be edited.
• Content types define where those sections can appear and how the page is structured.
• Your storefront code fetches content type entries and renders the referenced sections and components.

For a deeper dive into how schemas are organized, validated, and deployed, see Understanding CMS architecture and schema declarations.

FastStore ships with several native sections you can reuse or override before creating new ones. These examples apply specifically to FastStore projects, but the underlying concepts (page-placeable Sections composed of Components) apply to any storefront.

Some examples:

• Hero: Full-width banner used above the fold.
• ProductGrid: Product list typically used on PLP pages.
• Navbar: Top navigation bar.