Fields within the Admin Panel can be endlessly customized in their appearance and behavior without affecting their underlying data structure. Fields are designed to withstand heavy modification or even complete replacement through the use of Custom Field Components, Conditional Logic, Custom Validations, and more.

For example, your app might need to render a specific interface that Payload does not inherently support, such as a color picker. To do this, you could replace the default Text Field input with your own user-friendly component that formats the data into a valid color value.

Admin Options

You can customize the appearance and behavior of fields within the Admin Panel through the admin property of any Field Config:

1import type { CollectionConfig } from 'payload'
2
3export const CollectionConfig: CollectionConfig = {
// ...
fields: [
  // ...
  {
    name: 'myField',
    type: 'text',
    admin: { 
      // ...
    },
  }
]
15}

The following options are available:

Option	Description
`condition`	Programmatically show / hide fields based on other fields. More details.
`components`	All Field Components can be swapped out for Custom Components that you define. More details.
`description`	Helper text to display alongside the field to provide more information for the editor. More details.
`position`	Specify if the field should be rendered in the sidebar by defining `position: 'sidebar'`.
`width`	Restrict the width of a field. You can pass any string-based value here, be it pixels, percentages, etc. This property is especially useful when fields are nested within a `Row` type where they can be organized horizontally.
`style`	CSS Properties to inject into the root element of the field.
`className`	Attach a CSS class attribute to the root DOM element of a field.
`readOnly`	Setting a field to `readOnly` has no effect on the API whatsoever but disables the admin component's editability to prevent editors from modifying the field's value.
`disabled`	If a field is `disabled`, it is completely omitted from the Admin Panel.
`disableBulkEdit`	Set `disableBulkEdit` to `true` to prevent fields from appearing in the select options when making edits for multiple documents.
`disableListColumn`	Set `disableListColumn` to `true` to prevent fields from appearing in the list view column selector.
`disableListFilter`	Set `disableListFilter` to `true` to prevent fields from appearing in the list view filter options.
`hidden`	Will transform the field into a `hidden` input type. Its value will still submit with requests in the Admin Panel, but the field itself will not be visible to editors.

Field Components

Within the Admin Panel, fields are rendered in three distinct places:

Field - The actual form field rendered in the Edit View.
Cell - The table cell component rendered in the List View.
Filter - The filter component rendered in the List View.

To easily swap in Field Components with your own, use the admin.components property in your Field Config:

1import type { CollectionConfig } from 'payload'
2
3export const CollectionConfig: CollectionConfig = {
// ...
fields: [
  // ...
  {
    // ...
    admin: {
      components: { 
        // ...
      },
    },
  }
]
16}

The following options are available:

Component	Description
`Field`	The form field rendered of the Edit View. More details.
`Cell`	The table cell rendered of the List View. More details.
`Filter`	The filter component rendered in the List View. More details.
`Label`	Override the default Label of the Field Component. More details.
`Error`	Override the default Error of the Field Component. More details.
`Description`	Override the default Description of the Field Component. More details.
`beforeInput`	An array of elements that will be added before the input of the Field Component. More details.
`afterInput`	An array of elements that will be added after the input of the Field Component. More details.

* beforeInput and afterInput are only supported in fields that do not contain other fields, such as Text, and Textarea.

The Field Component

The Field Component is the actual form field rendered in the Edit View. This is the input that user's will interact with when editing a document.

To easily swap in your own Field Component, use the admin.components.Field property in your Field Config:

1import type { CollectionConfig } from 'payload'
2
3export const CollectionConfig: CollectionConfig = {
// ...
fields: [
  // ...
  {
    // ...
    admin: {
      components: {
        Field: '/path/to/MyFieldComponent', 
      },
    },
  }
]
16}

For details on how to build Custom Components, see Building Custom Components.

All Field Components receive the following props:

Property	Description
`docPreferences`	An object that contains the Preferences for the document.
`field`	The field's config. More details
`locale`	The locale of the field. More details.
`readOnly`	A boolean value that represents if the field is read-only or not.
`user`	The currently authenticated user. More details.
`validate`	A function that can be used to validate the field.

Sending and receiving values from the form

When swapping out the Field component, you are responsible for sending and receiving the field's value from the form itself.

To do so, import the useField hook from @payloadcms/ui and use it to manage the field's value:

1'use client'
2import { useField } from '@payloadcms/ui'
3
4export const CustomTextField: React.FC = () => {
5  const { value, setValue } = useField() 
6
7  return (
8    <input
9      onChange={(e) => setValue(e.target.value)}
10      value={value}
11    />
12  )
13}

TypeScript

When building Custom Field Components, you can import the component type to ensure type safety. There is an explicit type for the Field Component, one for every Field Type and for every client/server environment. The convention is to prepend the field type onto the target type, i.e. TextFieldClientComponent:

1import type {
TextFieldClientComponent,
TextFieldServerComponent,
TextFieldClientProps,
TextFieldServerProps,
// ...and so on for each Field Type
7} from 'payload'

The `field` Prop

All Field Components are passed their own Field Config through a common field prop. Within a Server Component, this is the raw Field Config. Within Client Components, however, the raw Field Config is non-serializable. Instead, Client Components receives a Client Config, which is a sanitizes version of the Field Config that is safe to pass into Client Components.

The exact shape of this prop is unique to the specific Field Type being rendered, minus all non-serializable properties. Any Custom Components are also resolved into a "mapped component" that is safe to pass.

1import React from 'react'
2import type { TextFieldServerComponent } from 'payload'
3
4export const MyServerTextField: TextFieldServerComponent = ({ payload, field: { name } }) => {
5  const result = await payload.find({
6    collection: 'myCollection',
7    depth: 1,
8  })
9
10  // ...
11}

Client Component:

1'use client'
2import React from 'react'
3import type { TextFieldClientComponent } from 'payload'
4
5export const MyClientTextField: TextFieldClientComponent = ({ field: { name } }) => {
6  return (
7    <p>
8      {`This field's name is ${name}`}
9    </p>
10  )
11}

The following additional properties are also provided to the field prop:

Property	Description
`_isPresentational`	A boolean indicating that the field is purely visual and does not directly affect data or change data shape, i.e. the UI Field.
`_path`	A string representing the direct, dynamic path to the field at runtime, i.e. `myGroup.myArray[0].myField`.
`_schemaPath`	A string representing the direct, static path to the Field Config, i.e. `myGroup.myArray.myField`

TypeScript

When building Custom Field Components, you can import the client field props to ensure type safety in your component. There is an explicit type for the Field Component, one for every Field Type and server/client environment. The convention is to prepend the field type onto the target type, i.e. TextFieldClientComponent:

1import type {
TextFieldClientComponent,
TextFieldServerComponent,
TextFieldClientProps,
TextFieldServerProps,
// ...and so on for each Field Type
7} from 'payload'

The Cell Component

The Cell Component is rendered in the table of the List View. It represents the value of the field when displayed in a table cell.

To easily swap in your own Cell Component, use the admin.components.Cell property in your Field Config:

1import type { Field } from 'payload'
2
3export const myField: Field = {
4  name: 'myField',
5  type: 'text',
6  admin: {
7    components: {
8      Cell: '/path/to/MyCustomCellComponent', 
9    },
10  },
11}

For details on how to build Custom Components, see Building Custom Components.

All Cell Components receive the following props:

Property	Description
`field`	The sanitized, client-friendly version of the field's config. More details
`link`	A boolean representing whether this cell should be wrapped in a link.
`onClick`	A function that is called when the cell is clicked.

The Label Component

The Label Component is rendered anywhere a field needs to be represented by a label. This is typically used in the Edit View, but can also be used in the List View and elsewhere.

To easily swap in your own Label Component, use the admin.components.Label property in your Field Config:

1import type { Field } from 'payload'
2
3export const myField: Field = {
4  name: 'myField',
5  type: 'text',
6  admin: {
7    components: {
8      Label: '/path/to/MyCustomLabelComponent', 
9    },
10  },
11}

For details on how to build Custom Components, see Building Custom Components.

Custom Label Components receive all Field Component props, plus the following props:

Property	Description
`field`	The sanitized, client-friendly version of the field's config. More details

TypeScript

When building Custom Label Components, you can import the component props to ensure type safety in your component. There is an explicit type for the Label Component, one for every Field Type and server/client environment. The convention is to append LabelServerComponent or LabelClientComponent to the type of field, i.e. TextFieldLabelClientComponent.

1import type {
2  TextFieldLabelServerComponent,
3  TextFieldLabelClientComponent,
4  // ...and so on for each Field Type
5} from 'payload'

The Error Component

The Error Component is rendered when a field fails validation. It is typically displayed beneath the field input in a visually-compelling style.

To easily swap in your own Error Component, use the admin.components.Error property in your Field Config:

1import type { Field } from 'payload'
2
3export const myField: Field = {
4  name: 'myField',
5  type: 'text',
6  admin: {
7    components: {
8      Error: '/path/to/MyCustomErrorComponent', 
9    },
10  },
11}

For details on how to build Custom Components, see Building Custom Components.

Custom Error Components receive all Field Component props, plus the following props:

Property	Description
`field`	The sanitized, client-friendly version of the field's config. More details

TypeScript

When building Custom Error Components, you can import the component props to ensure type safety in your component. There is an explicit type for the Error Component, one for every Field Type and server/client environment. The convention is to append ErrorServerComponent or ErrorClientComponent to the type of field, i.e. TextFieldErrorClientComponent.

1import type {
2  TextFieldErrorServerComponent,
3  TextFieldErrorClientComponent,
4  // And so on for each Field Type
5} from 'payload'

The Description Property

Field Descriptions are used to provide additional information to the editor about a field, such as special instructions. Their placement varies from field to field, but typically are displayed with subtle style differences beneath the field inputs.

A description can be configured in three ways:

As a string.
As a function which returns a string. More details.
As a React component. More details.

To easily add a Custom Description to a field, use the admin.description property in your Field Config:

1import type { SanitizedCollectionConfig } from 'payload'
2
3export const MyCollectionConfig: SanitizedCollectionConfig = {
// ...
fields: [
  // ...
  {
    name: 'myField',
    type: 'text',
    admin: {
      description: 'Hello, world!' 
    },
  },
]
15}

Description Functions

Custom Descriptions can also be defined as a function. Description Functions are executed on the server and can be used to format simple descriptions based on the user's current Locale.

To easily add a Description Function to a field, set the admin.description property to a function in your Field Config:

1import type { SanitizedCollectionConfig } from 'payload'
2
3export const MyCollectionConfig: SanitizedCollectionConfig = {
// ...
fields: [
  // ...
  {
    name: 'myField',
    type: 'text',
    admin: {
      description: ({ t }) => `${t('Hello, world!')}` 
    },
  },
]
15}

All Description Functions receive the following arguments:

Argument	Description
`t`	The `t` function used to internationalize the Admin Panel. More details

The Description Component

Alternatively to the Description Property, you can also use a Custom Component as the Field Description. This can be useful when you need to provide more complex feedback to the user, such as rendering dynamic field values or other interactive elements.

To easily add a Description Component to a field, use the admin.components.Description property in your Field Config:

1import type { SanitizedCollectionConfig } from 'payload'
2
3export const MyCollectionConfig: SanitizedCollectionConfig = {
// ...
fields: [
  // ...
  {
    name: 'myField',
    type: 'text',
    admin: {
      components: {
        Description: '/path/to/MyCustomDescriptionComponent', 
      }
    }
  }
]
17}

For details on how to build a Custom Description, see Building Custom Components.

Custom Description Components receive all Field Component props, plus the following props:

Property	Description
`field`	The sanitized, client-friendly version of the field's config. More details

TypeScript

When building Custom Description Components, you can import the component props to ensure type safety in your component. There is an explicit type for the Description Component, one for every Field Type and server/client environment. The convention is to append DescriptionServerComponent or DescriptionClientComponent to the type of field, i.e. TextFieldDescriptionClientComponent.

1import type {
2  TextFieldDescriptionServerComponent,
3  TextFieldDescriptionClientComponent,
4  // And so on for each Field Type
5} from 'payload'

afterInput and beforeInput

With these properties you can add multiple components before and after the input element, as their name suggests. This is useful when you need to render additional elements alongside the field without replacing the entire field component.

To add components before and after the input element, use the admin.components.beforeInput and admin.components.afterInput properties in your Field Config:

1import type { SanitizedCollectionConfig } from 'payload'
2
3export const MyCollectionConfig: SanitizedCollectionConfig = {
// ...
fields: [
  // ...
  {
    name: 'myField',
    type: 'text',
    admin: {
      components: {
        beforeInput: ['/path/to/MyCustomComponent'],
        afterInput: ['/path/to/MyOtherCustomComponent'],
      }
    }
  }
]
18}

For details on how to build Custom Components, see Building Custom Components.

Conditional Logic

You can show and hide fields based on what other fields are doing by utilizing conditional logic on a field by field basis. The condition property on a field's admin config accepts a function which takes three arguments:

data - the entire document's data that is currently being edited
siblingData - only the fields that are direct siblings to the field with the condition
{ user } - the final argument is an object containing the currently authenticated user

The condition function should return a boolean that will control if the field should be displayed or not.

Example:

1{
fields: [
  {
    name: 'enableGreeting',
    type: 'checkbox',
    defaultValue: false,
  },
  {
    name: 'greeting',
    type: 'text',
    admin: {
      condition: (data, siblingData, { user }) => {
        if (data.enableGreeting) {
          return true
        } else {
          return false
        }
      },
    },
  },
]
22}

Deploy your entire stack in one place with Payload Cloud.

Microsoft chose Payload to tell the world about AI.

Customizing Fields

Admin Options

Field Components

The Field Component

Sending and receiving values from the form

TypeScript

The `field` Prop

TypeScript

The Cell Component

The Label Component

TypeScript

The Error Component

TypeScript

The Description Property

Description Functions

The Description Component

TypeScript

afterInput and beforeInput

Conditional Logic

React Hooks

On this page

Deploy your entire stack in one place with Payload Cloud.

Microsoft chose Payload to tell the world about AI.

Customizing Fields

Admin Options

Field Components

The Field Component

Sending and receiving values from the form

TypeScript

The field Prop

TypeScript

The Cell Component

The Label Component

TypeScript

The Error Component

TypeScript

The Description Property

Description Functions

The Description Component

TypeScript

afterInput and beforeInput

Conditional Logic

React Hooks

On this page

The `field` Prop