Every Webflow CMS Field Type Explained

Webflow gives you 16 field types for structuring CMS content. Choosing the right one seems straightforward — until you realize that fields cannot be retyped after creation. Pick Plain Text when you needed Rich Text, and you delete the field, lose its data, create a new one, and re-enter everything. Pick Rich Text when Plain Text would have sufficed, and you lose the ability to bind that content to specific design elements.

Every field type decision is permanent and consequential. This guide covers all 16 types: what each one does, when to use it, the common mistakes people make, and what Trellis recommends based on patterns from hundreds of CMS architectures.

Plain Text

What it does: Stores a single line or short block of unformatted text. No bold, no italics, no links, no images. Just text.

When to use it: Headings, titles, labels, short descriptions, button text, meta titles, alt text, and any text that needs to be bound to a specific design element. Plain Text fields give you full styling control in the Designer — you can set the font, size, color, and spacing on the element, and the CMS text inherits those styles. For more detail, see the Plain Text field guide.

Common mistake: Using Rich Text for content that should be Plain Text. If the content will always be a single heading or a one-line description, Plain Text is correct. Rich Text adds formatting capabilities the content does not need and reduces your styling control in the Designer.

Trellis recommendation: Use Plain Text as your default for any text under 256 characters. Titles, subtitles, CTAs, labels, excerpts — all Plain Text. Reserve Rich Text for content that genuinely needs formatting.

Rich Text

What it does: Stores formatted text with support for headings, bold, italic, links, lists, images, videos, and embedded code. Rich Text is Webflow's version of a WYSIWYG editor. For the full breakdown, see the Rich Text field guide.

When to use it: Blog post bodies, article content, long-form descriptions, documentation pages, and any content where editors need to format text, add inline images, or create structured content with headings and lists.

Common mistake: Using Rich Text as a "catch-all" field. Every section of a page crammed into one Rich Text field. This gives editors flexibility but destroys design control. You cannot style individual sections independently, you cannot conditionally show or hide parts of the content, and you cannot bind sub-elements to other CMS fields. The result is a blob of content that looks different from the designed page.

Trellis recommendation: One Rich Text field per collection for the primary body content. Everything else — headings, excerpts, CTAs, image captions — should be separate Plain Text or Image fields. This preserves design control while giving editors a rich editing experience for the main content.

Image

What it does: Stores a single image with optional alt text. Supports JPG, PNG, GIF, SVG, and WebP. Images uploaded to Webflow are hosted on their CDN and automatically served in modern formats.

When to use it: Hero images, thumbnails, featured images, author photos, logos, and any single image that needs to be bound to a specific design element. Each image field holds exactly one image.

Common mistake: Creating multiple image fields for a gallery (Gallery Image 1 through Gallery Image 6). This burns field slots, hard-codes the maximum gallery size, and creates a tedious editing experience. Use the companion collection pattern instead — a separate "Gallery Images" collection with a reference back to the parent item.

Trellis recommendation: One to three image fields per collection: a hero/featured image, a thumbnail (for cards and lists), and optionally an OG image for social sharing. For galleries, Trellis automatically creates companion collections.

Multi-Image (Does Not Exist Natively)

What it does: Nothing — Webflow does not have a multi-image field type. This is one of the most requested features and one of the most common sources of confusion for people coming from other CMS platforms.

The workaround: Create a companion collection. A "Gallery Images" collection with an Image field, Alt Text, Sort Order, and a Reference field pointing back to the parent item. Display using nested collection lists filtered by the parent reference.

Trellis recommendation: If your source data has multiple images per item (Airtable's attachment field supports this natively), Trellis automatically creates and manages the companion gallery collection. You add images to your Airtable record. Trellis handles the structural translation to Webflow.

Video

What it does: Stores a video embed URL (YouTube, Vimeo, or other supported providers). Webflow generates the embed code and displays the video player. This is not a file upload — it is a link to an externally hosted video.

When to use it: Product demos, testimonial videos, course previews, and any embedded video content. Use it when the video is hosted on YouTube or Vimeo and you want Webflow to handle the embed.

Common mistake: Expecting file upload support. The Video field accepts URLs only. If you need to host video files directly, use the File field (for downloadable videos) or embed a video player via custom code in a Rich Text field.

Trellis recommendation: Use the Video field for embedded content. If a collection frequently has video content (like a courses collection), include both a Video field for the embed and an Image field for a custom thumbnail.

Link

What it does: Stores a URL. Can be an external link (full URL) or an internal link (relative path). Supports opening in a new tab.

When to use it: CTAs that point to external resources, registration links, partner website URLs, social media profile links, and any URL that needs to be editable in the CMS without touching the Designer.

Common mistake: Using Plain Text for URLs. Plain Text will store the URL string, but you cannot bind it to a link element's href attribute in the Designer. The Link field type is specifically designed for this binding. Use Link for clickable URLs, Plain Text for display-only URLs.

Trellis recommendation: Use Link fields for any URL that will be clickable on the site. Common uses: "Registration URL" on events, "Website" on partners, "CTA Link" on testimonials.

Email

What it does: Stores an email address. Webflow validates the format (must contain @). Can be bound to a mailto: link in the Designer.

When to use it: Contact email addresses for team members, department contact info, event RSVP addresses, and any email that should be clickable as a mailto: link.

Common mistake: Using Plain Text for email addresses. It works for display, but you lose format validation and cannot create mailto: links in the Designer without custom code.

Trellis recommendation: Use Email fields for all email addresses. They are semantically correct, provide validation, and enable one-click mailto: binding. One of the simplest field type decisions.

Phone

What it does: Stores a phone number. Can be bound to a tel: link in the Designer for click-to-call functionality on mobile devices.

When to use it: Contact phone numbers for team members, locations, businesses (in directory sites), and any phone number that should be tappable on mobile.

Common mistake: Using Plain Text for phone numbers. Same issue as email — it works for display but loses the tel: link binding and format hints.

Trellis recommendation: Use Phone for any phone number. Even if the design does not currently include click-to-call, using the correct field type means you can add that functionality later without restructuring.

Number

What it does: Stores a numeric value. Supports integers and decimals. Can be used for sorting, conditional visibility, and calculations (via custom code).

When to use it: Prices, sort order, ratings, quantities, years, numerical stats (square footage, capacity, distance), and any value that needs to be sortable or usable in comparisons.

Common mistake: Using Plain Text for numbers. Plain Text will store "42" but cannot sort it numerically — it sorts lexicographically, so "9" comes after "42." Number fields sort correctly and can be used for conditional visibility rules.

Trellis recommendation: Use Number for anything that might ever need to be sorted, filtered, or compared. Price, rating, year, quantity, sort order — all Number fields. Use Plain Text only for "numbers" that are really identifiers (ZIP codes, phone extensions, SKUs).

Date/Time

What it does: Stores a date and optional time. Webflow provides a date picker in the CMS editor. Dates can be formatted in the Designer (e.g., "March 15, 2026" or "03/15/26").

When to use it: Event dates, publication dates, expiration dates, project timelines, and any temporal data. Essential for date-based sorting and conditional visibility (showing only future events, hiding expired content).

Common mistake: Using Plain Text for dates ("March 15, 2026"). You lose date-based sorting, date formatting options in the Designer, and the ability to use conditional visibility based on date comparisons.

Trellis recommendation: Always use Date for temporal data. Include both a Start Date and End Date for events and time-bounded content. Add a Published Date separate from Webflow's system "Published On" field if you want editorial control over the displayed date.

Switch (Boolean)

What it does: Stores a true/false value. Displayed as a toggle in the CMS editor. Can be used for conditional visibility in the Designer.

When to use it: Featured flags (Featured on Homepage), visibility toggles (Show on Team Page), status indicators (Is Active), content gates (Is Premium Content), and any binary state that controls display or behavior.

Common mistake: Using an Option field with "Yes" and "No" values when a Switch would do. Switches are simpler, faster to toggle, and more intuitive for editors. Use Option only when you have more than two states.

Trellis recommendation: Use Switches liberally. They are lightweight, intuitive, and extremely useful for controlling content display. Every collection should have at least one: "Featured" for homepage curation, "Active" for visibility control, or "Show on Site" for draft management.

Option

What it does: Stores a single selection from a predefined list of choices. Displayed as a dropdown in the CMS editor. Can be used for filtering collection lists in the Designer.

When to use it: Status labels (Active, Completed, Archived), content types (Article, Video, Podcast), categories when they do not need their own pages, priority levels, department names, and any fixed enumeration.

Common mistake: Using an Option field when the choices need their own CMS items. If each "category" needs a landing page with a description, hero image, and SEO metadata, it should be a separate collection with a Reference or Multi-Reference — not an Option field. See Reference vs Option vs Multi-Ref for the full decision framework.

Trellis recommendation: Use Option for closed, stable lists with fewer than 15 choices. If the list changes frequently, grows beyond 15 items, or needs associated metadata, promote it to a collection with a Reference field.

Color

What it does: Stores a color value (hex code). Displayed as a color picker in the CMS editor. Can be bound to background colors, text colors, and border colors in the Designer.

When to use it: Category colors, brand accent colors for partner logos, team member theme colors, event type colors, and any per-item color customization.

Common mistake: Over-relying on per-item colors. Letting editors set arbitrary colors for each item leads to visual inconsistency. If you use Color fields, provide guidance on acceptable values or use them only for display accents (like a colored border or tag background) where variety is intentional.

Trellis recommendation: Use Color fields sparingly. They are useful for category indicators and brand colors but can create design chaos if used for primary styling. Prefer Option fields with named colors (Blue, Green, Red) that map to your design system's color tokens.

Reference (Single)

What it does: Links a CMS item to exactly one item in another collection. Creates a one-to-many relationship (one author has many posts, but each post has one author).

When to use it: Author on a blog post, brand on a product, department on a team member, parent category on a subcategory, program on an event. Any relationship where the item "belongs to" exactly one parent.

Common mistake: Using Multi-Reference when Single Reference is sufficient. If a blog post will always have exactly one author, use a Single Reference. Multi-Reference adds unnecessary complexity and consumes one of your five multi-reference slots.

Trellis recommendation: Single Reference should be your default relationship type. It has no item limit, does not count toward the multi-reference cap, and is simpler for editors. Only upgrade to Multi-Reference when the relationship is genuinely many-to-many.

Multi-Reference

What it does: Links a CMS item to multiple items in another collection. Creates a many-to-many relationship (a post has many tags, a tag appears on many posts).

When to use it: Tags, categories (when items can belong to multiple), speakers at events, products in multiple collections, and any genuinely many-to-many relationship. See the multi-reference field guide for detailed patterns.

Common mistake: Ignoring the limits. Multi-reference fields have a 100-item cap and a 5-fields-per-collection maximum. Both are hard limits with no upgrade path. Plan for them before you build.

Trellis recommendation: Use Multi-Reference deliberately, not as a default. Before creating one, confirm the relationship is genuinely many-to-many, that neither side will exceed 100 items, and that you have not already used your five multi-reference slots. If any of these conditions fail, use a junction collection or a companion collection with single references.

File

What it does: Stores a single uploaded file (PDF, document, spreadsheet, or other file type). Provides a download URL that can be bound to a link element in the Designer.

When to use it: Downloadable resources (annual reports, white papers, toolkits), document attachments, audio files, and any file that visitors need to download.

Common mistake: Using the File field for images. The File field creates a download link, not a displayable image. Use the Image field for visual content that should render on the page. Use File only for content that should be downloaded.

Trellis recommendation: Use File for downloadable content only. Pair it with a Plain Text field for the file title and a Plain Text field for the file description so editors can describe what they are offering without relying on the filename.

Slug

What it does: Stores the URL-friendly version of the item name. Auto-generated from the Name field but editable. Determines the item's URL path in collection pages.

When to use it: It is a system field — every collection has one automatically. You cannot add or remove it. You can edit its value to customize the URL for individual items.

Common mistake: Ignoring slugs until after launch. Slugs are generated from the Name field on creation. If you later rename an item, the slug does not update automatically — you must change it manually. If you do change it, the old URL breaks. Set up 301 redirects in Webflow's hosting settings whenever you change a published slug.

Trellis recommendation: Review slugs before initial publish. Keep them short, descriptive, and keyword-relevant for SEO. Once published, treat slugs as permanent — change them only with a redirect plan in place.

Field Type Decision Summary

How Trellis Chooses the Right Field Type

Field type decisions are one of the most consequential and least reversible parts of Webflow CMS architecture. Choose wrong, and you are deleting fields, losing data, and rebuilding. Choose right, and the CMS feels intuitive for editors and flexible for designers.

Trellis makes these decisions automatically. When you describe your content structure or connect an existing Airtable base, Trellis analyzes each field and maps it to the correct Webflow field type:

• Short text fields become Plain Text
• Long-form content becomes Rich Text
• Airtable attachments become Image fields (or companion gallery collections for multiple images)
• Airtable linked records become References or Multi-References based on cardinality
• Single-select fields become Options
• Checkboxes become Switches
• URLs become Links
• Emails become Email fields
• Phone numbers become Phone fields
• Dates become Date fields
• Numbers become Number fields

Every mapping follows the patterns in this guide — because these patterns were built from real-world experience and encoded into how Trellis makes decisions. You get the right field type every time, without needing to memorize the rules.

Frequently Asked Questions

Can I change a field type after creating it?

No. Webflow does not support retyping fields. If you chose Plain Text and need Rich Text, you must delete the field (losing all its data), create a new field with the correct type, and re-enter the content. This is why getting field types right during initial architecture is critical.

How many fields should a collection have?

Webflow allows 60 fields per collection (54 custom fields after the 6 system fields). Most well-structured collections need 10 to 25 fields. If you are approaching 40+, consider splitting into companion collections connected by reference. Under 10 fields often means you are using Rich Text as a catch-all instead of structuring content properly.

Should I use Rich Text or Plain Text for excerpts?

Plain Text. Excerpts are short, displayed in specific design contexts (cards, previews, meta descriptions), and should never contain formatting. Rich Text excerpts introduce formatting inconsistencies and break card layouts when someone accidentally bolds a word or adds a heading.

When should I use Color vs Option for category colors?

Use a Color field when each item needs a unique, arbitrary color. Use an Option field with named values (Blue, Green, Coral) mapped to your design system's color variables when colors should stay on-brand. Most sites are better served by the Option approach — it prevents editors from choosing clashing colors.

Is there a difference between the Name field and a Plain Text field?

The Name field is a system field that doubles as the item's identifier in the CMS editor. It auto-generates the Slug. Functionally, it behaves like a Plain Text field, but it cannot be deleted or renamed. You can add additional Plain Text fields for display titles that differ from the CMS item name.