Choosing a field type

Pick the type that matches what an editor is being asked for. The right type gives editors the right control, validates the value, and makes it easy to display later.

Quick guide

You want to store	Use
A short line of text: a tagline, a SKU	Text
A few plain sentences	Textarea
Formatted text with bold, links and lists	Rich text
Formatted text written in Markdown	Markdown
An email address, website, or phone number	Email, URL, Phone
A number: a capacity, a year, a weight of 1.4 kg	Number or Stepper
A value on a scale, or a from–to range	Slider or Range slider
A color	Color
A handful of short items: amenities, keywords	List
A code snippet or embed	Code
One option from a fixed list	Select, Radio Buttons or Button Group
Several options from a fixed list	Multiselect or Checkboxes
Yes or no	Switcher
A date, time, or date and time	Date, Time, Date & Time
A start and end date	Date range
Something that repeats: "every Saturday"	Recurring Date
One image, or several in order	Image or Gallery
An icon or logo that must stay sharp	SVG
A video or audio file	Video or Audio
Documents such as PDFs	Files
Terms from a taxonomy, as real WordPress terms	Taxonomy
A link to other posts or users	Select Post or Select User
A link both sides can see	Post Relation or User Relation
A set of fields that belong together	Group
The same set of fields, several times	Repeater
Rows that read like a spreadsheet	Field Table
Flexible page sections of different kinds	Content sections
Fields reused from another fieldset	Clone
An address with a map pin, or a drawn shape	Location or Area
A heading, note or spacer on the form itself	Layout fields

Common mix-ups

• Select vs Taxonomy. Use a Select for a fixed list that only labels an entry. Use a Taxonomy field when the list should have its own archive pages, counts or filters.
• Select vs dictionary. When the same list appears on several fields, keep it in a dictionary and link the fields to it.
• Select Post vs Post Relation. Select Post stores a link on one side only. A Post Relation keeps both sides in sync: add a Writer to a Book, and the Writer lists the Book.
• Group vs Repeater. Use a Group when a set of fields appears once. Use a Repeater when the same set repeats, like opening hours.
• Repeater vs Content sections. Use Content sections instead of a Repeater when each row can be a different kind of block.
• A field vs WordPress's own features. A post's title, main content, featured image and excerpt are built in. Don't recreate them as fields. See Keep the built-in features.

Changing a field's type later

Switch type in the field editor converts a field to another type, keeping its label and key. Stored values aren't converted. They're read the new way the next time they load, so switching between similar types (Text to Textarea) is safe, and switching between very different ones (Gallery to Text) isn't.

Technical details for LLMs

• Type keys by family: input text, textarea, rich_text, number, stepper, email, password, url, phone, color, list, slider, range_slider, code; choice select, multiselect, checkboxes, radio, button_group, switcher; dates date, date_range, time, datetime; media image, gallery, svg, video, audio; relational taxonomy, select_post, select_user; composite group, repeater; layout ui_heading, ui_spacer, ui_notice, ui_html.
• More type keys: input markdown; dates recurring_date; media files; relational post_relation, user_relation; composite table, content_sections, clone; geo location, area.
• Full per-type settings schemas: vx-framework/get-field-types with an explicit types list or include_schemas.
• Migrate stored values after a type change with Meta Watch (vx-framework/preview-field-migration); type compatibility is checked there.