Strapi Fields & Attributes — String, Number, Richtext, JSON, Media, and Enums

In this tutorial, you will explore every field type available in Strapi's Content-Type Builder, understand how to configure validation rules, default values, and constraints, and learn which field type to use for different kinds of content.

What You'll Learn

• All Strapi field types: string, text, richtext, number, boolean, date, email, password, JSON, media, enumeration, and UID
• How to configure field settings like required, unique, max length, and default values
• Which field type to choose for different content scenarios
• How field configurations affect the generated API
• Advanced field types like JSON and UID for special use cases
• Field validation and error handling

Why It Matters

Choosing the right field type determines how data is stored, validated, and exposed through the API. A wrong choice like using a string field for structured data instead of JSON forces your frontend to parse and validate the data manually. Understanding field types gives you full control over data quality and API ergonomics.

Real-World Use

A job board application has fields for job title (string, required), description (richtext), salary range (JSON with min/max/currency), company logo (media image), employment type (enumeration with full-time/part-time/contract), and a unique slug for each job posting (UID from title). Each field type serves a specific purpose and the frontend expects each in a specific format.

Learning Path

flowchart LR
  A["Content Types"] --> B["Fields & Attributes
-- You are here"]:::current
  B --> C["Relations"]
  C --> D["Components"]
  D --> E["Content Lifecycle"]
  E --> F["REST API"]

  classDef current fill:#4945ff,color:#fff,stroke-width:2px

String and Text Fields

String and text fields handle text content. The difference is length and formatting:

// Schema configuration for string fields
{
  "type": "string",
  "required": true,
  "maxLength": 200,
  "minLength": 10,
  "default": "Untitled",
  "unique": true  // No two entries can have the same value
}

Rich text fields store Markdown or HTML content. Strapi does not render the rich text. It stores the raw markup and returns it through the API. Your frontend is responsible for rendering it.

Use short text for fields that are displayed in lists, table columns, or search results. Use rich text for long-form content that needs headings, lists, and links.

Number Fields

Number fields store numeric values with configurable precision:

// Number field configuration
{
  "type": "float",
  "required": true,
  "min": 0,
  "max": 999999.99,
  "default": 0
}

The difference between float and decimal matters for financial data. float is approximate (IEEE 754). decimal is exact and should be used for prices, tax rates, and currency conversions. Internally, decimal maps to a fixed-point database column.

Boolean Fields

Boolean fields store true/false values. They are represented as toggle switches in the admin panel.

{
  "type": "boolean",
  "default": false
}

Use booleans for binary settings: featured status, published state, paid status, admin approval.

Date and Time Fields

Strapi provides five date/time field types:

{
  "type": "datetime",
  "default": "2026-06-28T00:00:00.000Z"
}

The datetime type is stored in UTC and can be formatted by the frontend to the user's timezone. The date type is timezone-agnostic, useful for birthdays or publish dates where time does not matter.

Enumeration Fields

Enumeration fields let you define a fixed set of valid values. The editor chooses from a dropdown.

{
  "type": "enumeration",
  "enum": ["easy", "medium", "hard"],
  "default": "medium"
}

Enums are stored as strings in the database. Changing the enum values after data exists can cause existing entries to have values no longer in the list. Strapi warns you about this but does not block it.

Use enumerations when a field has a limited, known set of options. If the options are dynamic or user-created, use a relation to another content type instead.

JSON Fields

JSON fields store structured data as JSON objects or arrays. This is the most flexible field type.

// Storing structured data in JSON
{
  "type": "json",
  "required": false
}

// Example data stored in a JSON field
// ingredients field:
[
  { "name": "flour", "amount": "2 cups" },
  { "name": "sugar", "amount": "1 cup" },
  { "name": "eggs", "amount": "3" }
]

JSON fields are powerful because they accept any valid JSON structure. However, this flexibility has a cost: you lose the ability to query individual fields within the JSON at the database level. Use JSON for unstructured or semi-structured data that you do not need to filter on.

Media Fields

Media fields attach files to entries. They support images, videos, audio, PDFs, and other document types.

{
  "type": "media",
  "allowedTypes": ["images", "files", "videos", "audios"],
  "multiple": true  // true for gallery, false for single image
}

You can restrict allowed types to specific categories. Setting allowedTypes to ["images"] limits the upload dialog to image files only. Setting multiple: true creates a gallery. Setting multiple: false means one file per field.

UID Fields

UID fields automatically generate unique, URL-friendly identifiers from another field.

{
  "type": "uid",
  "targetField": "title"  // Generate UID from the title field
}

// If title is "Classic Margherita Pizza"
// Generated UID: "classic-margherita-pizza"

UIDs are perfect for URL slugs. They are auto-generated when the entry is created and can be edited manually if needed. The system ensures uniqueness by appending a suffix if there is a collision.

Email and Password Fields

Email fields validate email format automatically. Password fields are hidden in the admin panel and have special handling in the Users & Permissions plugin.

{
  "type": "email",
  "required": true,
  "unique": true
}

Password fields are automatically hashed when stored. You cannot retrieve the original password through the API — only compare against it.

Field Configuration Reference

// Common configurations across field types
{
  "type": "string",
  "required": true,        // Entry cannot be saved without this field
  "unique": true,          // No duplicate values across entries
  "maxLength": 200,        // Maximum characters
  "minLength": 5,          // Minimum characters
  "default": "default",    // Default value for new entries
  "regex": "^[A-Z].*",    // Pattern validation (regex)
  "private": true          // Field excluded from API responses
}

The private setting is powerful for security. Mark sensitive fields like "internal_notes" or "salary" as private to exclude them from API responses while keeping them in the admin panel.

Common Mistakes

1. Using string where JSON is needed. Storing structured data (like an ingredients list) as a string forces the frontend to parse it manually. Use JSON for structured data that needs to remain structured.

2. Using float for prices. Float is approximate. Use decimal for accurate monetary values. A product priced at $9.99 might be stored as 9.99000000001 with float, causing display and calculation errors.

3. Not setting maxLength on string fields. Without maxLength, string fields have no limit. Editors can paste thousands of characters into a "name" field, causing database and rendering issues.

4. Adding too many fields to a single content type. Content types with 50+ fields are difficult to manage in the admin panel. Consider breaking them into related content types connected by relations.

5. Ignoring the unique constraint for slug-like fields. Without unique, two entries can have the same UID or slug, causing URL collisions. Always set unique on slug fields.

Practice Questions

1. What field type should you use for a product price? Answer: decimal for exact monetary values. Float is approximate and causes rounding errors.

2. What is the difference between a text (long) field and a richtext field? Answer: Text (long) stores plain text without formatting. Richtext stores Markdown or HTML with formatting. Richtext is for article bodies. Long text is for multi-line descriptions that do not need formatting.

3. When would you use a JSON field instead of creating a new content type? Answer: When the data structure is flexible or varies per entry, and you do not need to query individual fields. For example, an "attributes" field on a product that differs per product type.

4. Challenge: Design the fields for a hotel booking content type. Include at least: name, description, star_rating, price_per_night, amenities (structured list), photos (multiple), check_in_time, check_out_time, slug, and featured status. Choose the correct field type for each and justify your choices.

FAQ

Mini Project

Your task: Create a comprehensive content type with all field types.

1. Create a "Job Posting" collection type with the following fields:
   • title (string, required, maxLength 200)
   • description (richtext, required)
   • salary_range (JSON with structure {min: number, max: number, currency: string})
   • employment_type (enumeration: full-time, part-time, contract, freelance)
   • company_logo (media, single image)
   • location (string)
   • remote_available (boolean, default false)
   • publish_date (datetime)
   • slug (UID from title)
   • contact_email (email)
2. Add 5 sample job postings with realistic data.
3. Publish all entries and test the API.
4. Try sending invalid data (missing required field, wrong enum value) and observe the validation error response.

What's Next

Now that you understand field types, proceed to Relations to learn how to connect content types through one-to-one, one-to-many, many-to-many, and morph relations. After that, explore Components & Dynamic Zones for reusable field groups.

Related lessons:

• REST API Parameters — How fields are queried
• GraphQL — How fields become Graphql types
• Node.js — How Strapi validates field data