Gravity Forms Color Picker - WordPress Plugin

Guide to Setting Up and Using Gravity Forms Color Picker

Gravity Forms Color Picker is useful in forms where a plain text color choice is not enough for the actual task: a customer picks a product shade, a designer receives a HEX code for the mockup, a manager sees the color request in the entry, and the site owner wants the form to feel like more than a dry list of options. This guide focuses on practical use rather than the product listing itself: which fields to use, how to enable color swatches, how to turn on free-form color selection, how to verify the submission, and where to look if the swatches do not appear on the site.

The plugin works around standard Gravity Forms fields, so a solid setup starts not with picking a pretty theme but with understanding the field's role. Radio Buttons provide one required option from a prepared palette. Checkboxes work when the user can select multiple colors. Single Line Text becomes a popup for choosing any HEX value when a predefined palette is too limited. That distinction affects validation, notifications, conditional logic, design, and how the submission is handled afterward.

This guide is written for site owners, editors, developers, and support specialists who already understand the basics of Gravity Forms and want to add color selection cleanly without drifting into random CSS tweaks. We will go from preparation and installation to an advanced product visualizer workflow, then look separately at limitations, similar solutions, and the questions that usually come up after the first test.

The key practical takeaway: Gravity Forms Color Picker does not replace your entire form builder, and it does not turn a form into a full design editor. It adds controlled color behavior exactly where the form needs it. If you choose the right field type, value format, and verification flow, the plugin becomes a clear working tool rather than decorative add-on clutter.

Where Color Selection Actually Improves a Form

Color is rarely needed in a form for its own sake. It matters when the selected shade affects the order, the brief, the layout, submission routing, or a visible outcome on the page. If a user simply types "blue" into a text field, the administrator gets an ambiguous answer: that could mean navy, sky blue, turquoise, or a specific brand color. A color swatch paired with a HEX value reduces that uncertainty.

Gravity Forms Color Picker works especially well in forms where color choice is part of the decision, not just interface decoration. Examples include print orders, selecting a T-shirt or accessory color, a logo design request, choosing a background shade for a personalized content block, configuring a digital product, an internal request form for marketing assets, or a client feedback form used to approve a project palette. In those use cases, the color field helps not only the visitor but also the person reviewing the entry later.

There is a downside too. If the form is only collecting a standard contact request, newsletter signup, consultation request, or service booking with no color-related outcome, Color Picker can make the interface harder to use. The user ends up spending attention on a choice that does not help process the request. In those cases, it is better to keep standard Gravity Forms fields and improve the form through descriptions, hints, conditional logic, or short answer choices.

Controlled Palette vs. Free-Form HEX

The first decision is whether to allow only prepared colors or give the visitor a full color wheel. A controlled palette makes sense when the business truly supports a limited set of options. If a workshop produces an item in six colors, the form should show those six colors, not the entire spectrum. In that case, Radio Buttons or Checkboxes with colors enabled help the user quickly pick an available option, while the administrator receives a value that matches the internal workflow.

Free-form HEX works better for creative tasks: a design brief, selecting a background color, custom branding, or requesting a signature shade. In that case, Single Line Text with Color Picker enabled is the more logical choice because the field stores the exact color value as text. A HEX code is a color value written like #1d1d1f, which can be passed to a designer, used in CSS, or stored in the entry without having to describe it in words.

The problem starts when free-form HEX is offered in an order form for a physical product with limited stock. The customer picks a shade that is not actually available, and the manager has to negotiate a replacement manually. For that kind of form, it is usually better to keep a prepared set of swatches and add an "Other" option only if the team is truly ready to handle custom colors.

Who the Plugin Works Well For

The plugin is a strong fit for WordPress sites where Gravity Forms is already the backbone of request forms or custom order forms. It works well for agencies, small shops, print studios, makers of custom products, educational projects with creative assignments, designers collecting briefs, and internal teams that need to organize client color requirements in a structured way.

Another strong point is that it works with existing forms. According to JetSloth documentation, the plugin enhances standard Radio, Checkbox, and Single Line Text fields. That means you do not have to rebuild a form from scratch just to add color selection. In many cases, it is enough to open the field you need, enable colors, and clean up the choices.

Who It May Not Be Right For

Gravity Forms Color Picker may be unnecessary if you do not use Gravity Forms, if the form needs to stay extremely simple, if color does not affect how the submission is processed, or if you need a full visual editor with image saving, layers, canvas, and export. JetSloth shows advanced tutorial workflows where Color Picker is connected to CSS and JavaScript, but that is customization on top of the base behavior, not a ready-made replacement for a design application.

Another case that calls for caution is forms with strict accessibility and contrast requirements. Color swatches should never be the only carrier of meaning. They need readable labels, values, or descriptions alongside them, because some users cannot distinguish shades or rely on assistive technologies. If the user is making a legally, financially, or commercially significant decision, color should always be reinforced with text.

How the Plugin Fits into Standard Gravity Forms Fields

The most important thing about Gravity Forms Color Picker is that it does not force administrators to learn a separate custom field type. Based on the official JetSloth pages and the Gravity Forms marketplace listing, the plugin adds color pickers and swatches to Radio Buttons, Checkboxes, and Single Line Text. So the form's core behavior stays familiar: the field still lives in the Form Editor and still uses labels, choices, appearance settings, validation, conditional logic, and merge tags within the normal Gravity Forms workflow.

That reduces the chance of errors. If you already know how a Radio Buttons field works, you know the user picks one option. If you know Checkboxes, you know the user can select multiple values. If you know Single Line Text, you know the outcome is stored as a text value. The plugin adds a color layer and display tools, but it does not override the core rules of Gravity Forms.

Radio Buttons: One Color from a Known Palette

Radio Buttons are the right choice when exactly one option should be selected. The user picks one swatch, and the form stores one value. This is useful for product colors, a primary logo color, a finish option, a theme choice, a selected background, or a status-like value where multiple selections do not make sense.

Gravity Forms documentation specifically notes that Radio Buttons validate the submitted value against the configured choices. That matters for Color Picker: if you use a prepared palette and do not enable a free-form "Other" path, the entry stays controlled. The administrator does not end up with something like "almost red, but lighter" instead of a value the workflow actually supports.

If your choices use complex labels, HTML entities, or values with special characters, Gravity Forms recommends enabling Show Values and assigning simple unique values. That is especially helpful for color options. The label can stay user-friendly, for example "Warm Orange," while the value remains technically stable, such as orange-warm or #fea730, if that format is needed downstream.

Checkboxes: Multiple Colors in One Submission

Checkboxes are a better fit when the user can choose multiple colors at once. For example, a client may be ordering a sticker pack, selecting multiple accent shades for a brand kit, or marking all colors that are acceptable for a product batch. In that kind of setup, a single Radio Buttons field would be too restrictive, while several separate text fields would make the entry messy.

With Checkboxes, it is especially important to decide in advance how the team will read the outcome. If the user can select four colors, the notification needs to be clear: the names, values, or swatches should make it obvious what was selected. JetSloth notes that Color Picker can display swatches in admin entries and email notifications, but you still need to verify the exact output with a test submission because the notification template, email theme, and other add-ons can affect how it appears.

Single Line Text: A Custom Color Through a Popup

Single Line Text with Color Picker enabled solves a different problem. According to JetSloth documentation, when you enable "use colors" on a single line text field, the user gets a popup color selector rather than a predefined set of swatches. This is a good fit for fields like "Brand Color," "Background Color," "Text Color," "HEX Shade," or "Primary Layout Color."

The practical advantage is that the value remains text-based. It is easier to insert into a notification, pass to a designer, save in a CRM, or use in a careful custom workflow. The practical downside is that free input needs review. The user may choose a shade that is hard to read on white, conflicts with a brand guide, or is not available in production. That is why it helps to add a brief description next to the field: HEX values are accepted, the final shade will be reviewed before use, and very low contrast may require adjustment.

"Other" as a Bridge Between a Palette and Free Choice

Radio Buttons can include an "Other" choice. JetSloth describes a workflow where radio or checkbox fields present swatches, while "Other" gives the user a way to specify their own color. It is a compromise: the form offers a safe default palette without blocking an unusual request.

This mode should only be enabled deliberately. If the business is not prepared to handle custom colors, "Other" will create more questions than value. If custom colors are allowed, the field should clearly explain what happens next: a manager confirms availability, a designer checks contrast, production approves the material, or the system stores the HEX value as a user-specified option.

What to Check Before Installing on a Live Site

Preparing for Color Picker is similar to preparing for any Gravity Forms add-on, but there are a few product-specific details. The plugin affects field appearance, loads its own assets only where forms contain color picker fields, and may interact with the Gravity Forms theme, custom CSS, and third-party add-ons. The right order is to check the platform and the form first, install second, and then test not only the admin side but also the public-facing page.

Platform Requirements and the Gravity Forms Dependency

Gravity Forms Color Picker is an add-on for Gravity Forms. Gravity Forms itself must already be installed and active on the site. The official Gravity Forms documentation explains installation through the WordPress dashboard or FTP, and for add-ons through the Add-On Browser or a ZIP upload in Plugins. This guide does not cover purchasing, account setup, or licensing, because those are not part of configuring the form itself. What matters here is simpler: before you roll it out, make sure you have WordPress administrator access, access to edit Gravity Forms, and a test page where you can safely submit the form.

The JetSloth changelog shows that newer releases have addressed PHP requirements, Gravity Forms theme framework compatibility, Multi Choice field support, enqueue condition changes, and integration with Gravity Perks Populate Anything. So before updating on a live site, it is worth checking the system requirements for the current plugin version and for Gravity Forms, but the guide should not tie the setup to one specific version number. Versions change, but the principle stays the same: staging or backup first, then enable it on the form, then submit a test entry.

The Existing Form and Field Types

Open the form where color selection is needed and list every place where color affects the outcome. Do not start with "which swatch theme looks nicer." Start with the data map:

• Which field should store the color: Radio Buttons, Checkboxes, or Single Line Text.
• Whether the user should choose one color, several colors, or a custom HEX value.
• Whether an "Other" option is needed, and who will handle custom colors.
• Where the color should appear after submission: the entry, email notification, confirmation, product calculation, internal comment, or a visual block on the page.
• Whether the value should participate in conditional logic, routing, pricing, or another add-on.

If color affects conditional logic, keep the values simple. Gravity Forms warns that special characters and HTML in field values can interfere with conditional logic, calculations, dynamic population, and validation. That is easy to miss with swatches: the label can look polished, but the value still needs to be predictable.

Theme Styling and Custom CSS

Gravity Forms uses the Theme Framework and the Orbital theme for modern form styling. The JetSloth changelog specifically includes fixes related to the Gravity Forms theme framework and legacy mode. That is a signal to check not only plugin settings before rollout, but also how the current site theme overrides form styling.

If the site already has custom CSS for radio buttons or checkboxes, custom classes, a layout editor, or old CSS Ready Classes, the swatches may inherit unexpected sizes, margins, border colors, or display behavior. A good preparation step is to temporarily open the form on a page without extra layout blocks, verify the clean output, and only then move the field into the real layout.

Cache, Minification, and Re-Embedding the Same Form

Color Picker runs on the public-facing site, where caching, JavaScript optimization, CSS combining, and lazy-loaded blocks are often enabled. The JetSloth changelog mentions enqueue conditions: assets should load only on pages where the form contains color picker fields. That is good for performance, but it creates a common troubleshooting question: if swatches do not appear, you need to verify whether the assets loaded on that specific page and whether the site is still serving an older cached version of the form.

Another common Gravity Forms risk in general is embedding the same form multiple times on one page, for example both in page content and in a popup. With dynamic add-ons and custom handlers, that can lead to ID conflicts, events firing in the wrong place, or visual glitches. If the form needs to appear in two locations, it is usually safer to duplicate the form and use different form IDs than to force one instance to live in multiple containers at once.

Installation and Initial Verification Without Unnecessary Risk

Installing a Gravity Forms add-on follows the normal WordPress plugin workflow. If the add-on is available in the Gravity Forms Add-On Browser, the path starts under Forms > Add-Ons. If you have a ZIP archive, the standard WordPress path is Plugins > Add New > Upload Plugin, then select the file, install it, and click Activate Plugin. After activation, check whether Color Picker appears in form settings and field settings.

Do not enable the plugin first on the most complex form on the site. Create or copy a short test form with one Radio Buttons field, one Checkboxes field, and one Single Line Text field. That gives you fast feedback: you can see how the plugin behaves with each field type without mixing the issue into conditional logic, payment add-ons, multi-page forms, or custom scripts.

Minimum Test Form

For the first check, a three-field form is enough:

1. Radio Buttons: "Primary Color," with choices "Blue," "Orange," "Red," and optionally "Other."
2. Checkboxes: "Additional Colors," with choices "Black," "White," and "Green."
3. Single Line Text: "Custom HEX," enabled as a color picker.
4. An Email or Hidden field if you need to test notification routing or merge tags.

After saving the form, open both the preview in the Form Editor and the page where the form is embedded through a Gravity Forms block. You need to test both locations. The JetSloth documentation has included fixes for editor preview, so correct behavior in the admin area and correct behavior on the site are two separate checks.

What Counts as a Successful Installation

The installation is successful if a field with Color Picker enabled shows swatches or a popup, the selected color changes visually on click, the form submits, the entry contains the expected value, and the notification displays the color in a readable way. If the swatch appears but the entry is empty, the problem is not the design but value handling. If the entry is correct but the email looks wrong, the issue is in the notification template or the swatch output mode.

Do not treat the first nice-looking color click as the end of setup. Submit the form, open the entry, check the email notification, and repeat the test in a browser where you are not logged in. That is what shows whether the product works in a real visitor workflow.

Where to Find the Settings After Activation

According to JetSloth documentation, the appearance of a color picker field is adjusted through the Color Picker tab in the field settings sidebar, while part of the behavior may be global or form-specific. In practice, it helps to separate settings into three levels:

• Field level: enable colors, swatch or color value, display theme, custom colors, and field-specific styling.
• Form level: overall appearance, layout choices, notification and confirmation checks, and CSS class wrapper behavior.
• Site level: cache, the Gravity Forms theme, custom CSS, external add-ons, and JavaScript handlers.

That order helps isolate causes. If only one field looks wrong, the problem is probably in the field settings or field-specific CSS. If all color picker fields on the form are broken, look at form-level settings, legacy mode, the theme framework, and assets. If the issue happens on only one page, the likely cause is cache, the page builder, a popup, or something specific to that page environment.

Detailed Setup for Color Fields After Installation

Configuring Color Picker should answer several questions: what the user is selecting, how it looks, what value is stored, where that value is shown, and how the outcome is verified. None of those can be replaced by the vague advice to "configure it for your needs." Below is a practical sequence that works for most forms.

Step 1. Name the Field So the Entry Makes Sense Without a Screenshot

The field label should be clear to both the user and the administrator. "Select Color" may be fine as a demo label, but on a real site, it is better to be specific: "Case Color," "Primary Logo Color," "Print Color," or "Banner Background Color." If you use multiple color picker fields, the labels should be distinct enough that the notification does not turn into a list of identical "Color" entries.

An Admin Label is useful for internal workflows. Gravity Forms merge tags and entry details may refer to the field ID and label, so careful naming reduces confusion. If the public label needs to stay short, the admin label can be more precise: "Brand primary HEX," "T-shirt body color," or "Sticker accent color." It is often best to keep those technical labels in the admin area and show the user a more natural label.

Step 2. Choose the Field Type Based on the Outcome

Use Radio Buttons for one value. Use Checkboxes for multiple values. Use Single Line Text for a free-form HEX value. If you are tempted to use Single Line Text only because the color wheel looks more impressive, stop and check the business logic first. Free-form color works best where inventory limits do not apply. In product catalogs, printing, packaging, and finishes, a limited palette is often the safer choice.

How to Choose a Field for Gravity Forms Color Picker

Task	Field	Why This Works	What to Verify
One available product color	Radio Buttons	The user selects exactly one option from prepared choices.	The entry contains one label or value, and the selected swatch is highlighted.
A set of allowed colors	Checkboxes	The user can choose multiple swatches without needing several duplicate fields.	The notification shows all selected values.
A brand color or custom shade	Single Line Text	The plugin opens a color wheel popup and stores the HEX value as text.	The entry contains the expected HEX value and does not go blank after submission.
Standard palette plus a custom request	Radio Buttons with "Other"	The main choices stay controlled, and the custom color remains an exception path.	The Other value is preserved in the entry and visible in the email.

Step 3. Configure Choices and Values

For Radio Buttons and Checkboxes, add choices in the standard Gravity Forms editor. Then enable color behavior for the field and assign a color to each choice. If a choice is used in conditional logic or calculations, it is usually better to enable Show Values and assign simple stable values. For color, you can store either a clear slug or a HEX code. The right choice depends on how the downstream system reads the result.

A slug is convenient for business logic: orange, navy, sand. HEX is convenient for design and automatic visual output: #fea730, #0275ff, #ff0152. Do not mix the two approaches accidentally. If a manager needs to read the entry without a reference sheet, the label should remain understandable even when the value is technical.

Step 4. Pick a Display Theme That Fits the Form Context

JetSloth lists six display themes: Pantone, Shadow Box, Circle, Horizontal Bar, Compact, and Lozenge. This is not just cosmetic. The theme affects how quickly the user can recognize options, whether the choices fit the layout, whether the label stays visible, and how easy the color is to select in a multi-step form.

Pantone works well for design briefs and cases where color should feel like a sample. Circle is usually faster to scan for a quick shade choice. Horizontal Bar can work well when choices sit in a row and labels should not take up too much space. Compact is useful in dense forms, but it requires caution: the smaller the swatch, the more important the text label and contrast become. Lozenge can feel like a clean selection chip when the form needs a more modern appearance.

A safe default: choose a theme where both the color and the label are visible without hover. Do not rely on the shade alone as the only signal of meaning.

Step 5. Check the Layout on Desktop, Tablet, and Mobile

The JetSloth product page mentions layout settings that let you control the number of columns across desktop, tablet, and mobile, as well as alignment options such as left, center, or right. That matters more than it may seem. Swatches that look clean in two rows on desktop can collapse into a cramped vertical stack on mobile. And a very wide horizontal row can overflow a narrow sidebar or popup container.

Do not test only on a regular page. Test where the form will actually be used: a landing page, WooCommerce product page, modal window, page builder tab, protected account area, or multi-page form. If the form sits in a narrow container, it is often better to reduce the number of columns and leave more breathing room between choices.

Step 6. Configure Output in Entries and Notifications

JetSloth gives you a choice: display values as plain text or as swatches in admin entries and email notifications. Text is easier to search, copy, and export. A swatch is faster to read visually, especially when a manager is processing color-based submissions. The best choice depends on the workflow.

If submissions go into a CRM, spreadsheet, or automated pipeline, a text value is usually safer. If a manager is manually reviewing shades, a swatch in the notification may help. But email clients do not all render HTML the same way: one may simplify styles, hide parts of the formatting, or resize elements. So test the admin entry and the email separately.

Step 7. Document the Rollback Path

Before enabling the field on a live form, make a short note in your project documentation: which fields received Color Picker, which theme is selected, whether legacy mode is enabled, where CSS or JS was added, and where to verify the result. If something breaks after a site update, that record saves time. Rolling back is usually simple: remove "Use Colors" from the field, switch the display theme, enable legacy mode, disable custom CSS, or temporarily remove the custom handler.

Preset Swatches and Free-Form HEX: Two Different Behaviors

To the user, both look like "choosing a color," but inside the form they are two different mechanisms. The first is choosing from predefined options. The second is entering a custom value through a popup. That difference matters because controlled choices and free input create different risks for submission handling.

How Swatches Work in Radio Buttons and Checkboxes

When you add swatches to Radio Buttons or Checkboxes, the color sample becomes a visual representation of a choice. The user clicks the color, and Gravity Forms stores the selection as the normal value of that field. This works well with conditional logic: you can reveal extra fields when a specific color is chosen or send the notification to another team when the user selects a nonstandard option through "Other."

The important point here is not to confuse the displayed color with the stored value. The swatch may be bright orange, the label may be "Orange," and the value may be #fea730 or orange. If you use the value later in an email or integration, verify that the saved value is actually what the recipient expects. A good-looking swatch does not guarantee the right stored value.

How the Custom Color Popup Works

Single Line Text with Color Picker enabled acts as a free-form color input. The user opens the color wheel, picks a shade, and the field receives a HEX value. That is not a good fit for inventory or price lists, but it works very well in a technical brief. A designer can work much more easily with #4c6a86 than with a phrase like "muted blue-gray."

Add a short description to the field. For example: "Choose a color or enter a HEX value. We will review contrast before applying it to the mockup." This is not marketing copy; it is a way to reduce disputed requests. The user understands that the choice is accepted as an initial preference, not as an irreversible promise of the final outcome.

When to Combine Both Approaches

A combination of swatches and "Other" works well in forms that have a standard palette but allow exceptions. For example, a print studio may offer core colors while still allowing a client to request a custom brand shade. In that case, a useful pattern looks like this:

1. Start with a clear palette of available colors.
2. Name the final option "Other" or the equivalent in the form's language.
3. Use the field description to explain that a custom color requires review.
4. Make sure the notification highlights the custom color so the manager does not mistake it for a standard stock option.

If the custom color also requires a file, a comment, or a link to brand guidelines, do not try to force everything into one color field. Add a conditional block instead: when "Other" is selected, show a Single Line Text field for HEX, a Paragraph Text field for comments, or a File Upload field for brand references. Gravity Forms conditional logic is exactly what makes this kind of workflow manageable.

Display Themes, Grid Layout, and Swatch Readability

The Color Picker display theme is an interface decision, and it should match what the form is trying to do. One theme emphasizes the sample itself, another saves space, and another sits more naturally next to product options. Do not choose a style just because it looks most dramatic in the demo. Check the size, the label, the number of choices, the container width, and how it behaves on different screen sizes.

How to Choose a Theme Without Relying on Taste Alone

Start with a simple question: what does the user need to notice first, the color itself, the color name, or the connection to the product? If the exact visual shade matters most, you need a larger swatch. If the goal is a quick pick from known names, a more compact style with a strong label can work well. If the form is long, oversized swatches can overload the page and push the Submit button further down than necessary.

For a creative brief, a Pantone-style presentation often makes sense because it feels like a palette. For ordering a straightforward product, Circle or Lozenge may be faster to use. If there are many colors, it is usually better to avoid an overly decorative theme, because the user may start treating the form like a design catalog instead of a simple request form.

Columns and Alignment

Layout settings help control how many swatches appear in a row on desktop, tablet, and mobile. A good grid should keep the label readable while making the swatch large enough to tap or click comfortably. If there are only a few choices, center alignment can look polished. If there are many, left alignment is often easier to scan because the eye moves top to bottom with less jumping.

On mobile, do not force the desktop grid to survive at all costs. One or two columns with normal spacing are better than four tiny swatches that users tap by mistake. If the form appears in a popup, check the height too: the swatches should not push the submit button below the visible area without a good reason.

Text Next to the Color

A color swatch should not be the only explanation. Add a label, value, or description. That matters for accessibility and support alike. A manager can discuss "Orange" or "Warm Orange" with a client, but may not be able to clearly describe "the third square from the right."

If the color names are marketing-driven, such as "Sunset," "Ocean," or "Graphite," add the technical value in the admin area or in the order notes. A polished name helps the user choose, but the team still needs a stable connection to the HEX value, SKU, or internal variant.

What Happens After Submission: Entry, Notification, and Verifying the Outcome

The real value of Gravity Forms Color Picker shows up after the user clicks Submit. The visitor sees a confirmation, the administrator receives an entry, email sends a notification, and in some cases the selected color affects a visual block or conditional logic. If you only checked the swatch appearance before submission, half the work is still unfinished.

The Entry as the Source of Truth

After a test submission, open the entry in Gravity Forms. Confirm that the selected color was not lost, did not unexpectedly switch from value to label or vice versa, and was not saved as empty. If swatch display is enabled, make sure the entry remains understandable not only visually but also in text. For a support team, the entry needs to stay readable even a month later, when nobody remembers exactly what the swatch looked like on the form.

If the field value is used for export, CRM, or downstream processing, the text format matters more than a pretty thumbnail. You can display a swatch in the admin area while storing a stable value. That separation is especially useful when the color is used in automated email, internal routing, or integration logic.

Notification: When a Swatch Helps and When It Gets in the Way

Gravity Forms notifications support merge tags, and JetSloth notes that swatches can be shown in email notifications. But email clients vary widely in how they handle HTML and styling. So the rule is simple: if the recipient needs the color to be unambiguous, the notification should include both a visual cue and a text value. For example: "Case color: Orange (#fea730)."

If the email goes to the customer, do not overload it with technical details. If it goes to production or a designer, the HEX value may be essential. You can create different notifications for different recipients using conditional logic or a different set of merge tags. That is already standard Gravity Forms behavior, and Color Picker simply gives you a more precise value to work with.

Confirmation: What to Show the User After Submission

Gravity Forms confirmations show a message, a page, or a redirect after a successful submission. In color picker workflows, the confirmation can reduce uncertainty: "We received your selected color and will verify shade availability." If the color choice affects the next step, the confirmation can send the user to an instruction page, but it should not promise automatic application if the request is still going through human review.

For a custom color submitted through "Other," it is better to phrase the confirmation carefully. For example: "Thank you, we received your custom color and will compare it with the available palette." That is more honest than "color accepted" if the business process still includes manual approval.

Testing as a Regular Visitor

After configuration, log out of the admin area or open the page in a private window. Test the form the way a visitor would: swatches are visible, labels are readable, the color wheel opens, keyboard navigation does not break input, Submit works, and the error state does not hide the selected color. If the form only works for an administrator, the cause may be cache, permissions, asset loading, conditional logic, or page builder scripts.

Minimum successful test: choose a color, submit the form, see the confirmation, open the entry, receive the notification, then repeat the test after clearing cache and at a mobile width.

Use Case: A Color Selection Form for a Custom Product

Let us walk through a practical example that shows the value of Color Picker better than a generic feature list. Imagine a site that accepts requests for custom T-shirt printing with a limited palette plus an additional field for a custom shade. The goal is for the user to select the main product color, optionally provide a HEX value, and give the manager a clear submission to work with.

Goal

We want a form where the customer chooses one standard T-shirt color from prepared swatches. If none of the standard colors fit, they choose "Other," enter a HEX value, and add a comment. After submission, the manager can see the primary selection, understand whether it is standard, and quickly review the custom shade if needed.

Preparation

The site should already have Gravity Forms, Gravity Forms Color Picker, and a page for the test form. You also need a palette in advance, for example Blue, Orange, Red, Black, White, and Other. For each standard color, define both the label and the value. If production uses internal codes, the value can be the color code. If the design team works with HEX, the value can be the HEX code.

For this example, we will assume the standard values look like blue, orange, and red, while a separate Single Line Text field stores the HEX value only when the custom path is selected. This is not the only correct approach, but it cleanly separates the stock palette from the custom request.

Setup Steps

1. Create a new form or duplicate an existing order form so you do not disrupt the live workflow.
2. Add a Radio Buttons field labeled "T-shirt Color."
3. Add the choices Blue, Orange, Red, Black, White, and Other.
4. Enable Show Values if the values will be used in conditional logic, notifications, or integrations.
5. Enable Color Picker behavior for the Radio Buttons field and assign a swatch to each standard choice.
6. Choose a display theme. For products, Circle, Shadow Box, or Lozenge often work well as long as the label stays visible.
7. Add a Single Line Text field labeled "Custom Color HEX." Enable Color Picker for that field.
8. Add a Paragraph Text field labeled "Color Notes" if the manager needs more context.
9. Enable conditional logic so the HEX field and comment appear only when the Radio Buttons value is Other.
10. Configure the notification so it includes both the main color and the custom HEX value when the custom path is selected.

Verification

First, submit a standard order with Orange selected. The entry should contain "T-shirt Color: Orange" or the corresponding value, the HEX field should stay empty or hidden, and the notification should not mislead the manager. Then submit a custom order: select Other, enter #4c6a86, add a comment, and verify that both fields appear in the entry.

If a hidden conditional field remains empty and does not participate in the downstream process, that is normal. Gravity Forms conditional logic usually does not store data from hidden fields the same way it stores an active visible choice. So be sure to test the actual path where the field is shown and filled out.

Common Pitfall: Do Not Mix Pricing with Simple Color Choice

If color affects pricing in WooCommerce or Gravity Forms pricing flows, standard Radio Buttons or Checkboxes are not always the correct place to carry price logic. In those workflows, you need to verify which field type is required by the add-on that controls product options. The WooCommerce Gravity Forms Product Add-Ons documentation, for example, specifically points to the Product Option field type for options that carry a cost. Color Picker can improve the visual selection, but the pricing logic still needs to live in the field type and add-on that actually support it.

Practical takeaway: configure the order logic first, then improve the color interface. Do not try to fix pricing, stock, or availability with one attractive palette.

How to Use the Selected Color in the Page Design

One of JetSloth's more interesting workflows is using the selected color to change elements on the page. The documentation describes classes such as gfcp_bg, gfcp_color, gfcp_border, gfcp_fill, along with the format gfcp_{selectorClass}_{form_id}_{field_id}, which listens to a specific field in a specific form. At that point, the form is doing more than showing swatches. It creates a connection between user input and a visible effect.

This approach works well for a product visualizer, a mini configurator, a logo preview, a banner preview, or a simple design flow where the user wants immediate feedback. JetSloth's product visualizer tutorial shows a combination of standard Gravity Forms fields, Color Picker, an HTML preview area, CSS, and JavaScript. But this is exactly where you need to be careful to separate documented behavior from custom adaptation.

Basic Integration Through CSS Classes

If the page contains an element whose color should respond to the user's selection, you can add a documented JetSloth class to it. For example, a preview block can change its background color through gfcp_bg, while a heading can change text color through gfcp_color. If the page has one form and one color field, the general class may be enough. If there are multiple forms or fields, use the scoped format with the form ID and field ID.

The careful custom adaptation below is based on the documented JetSloth classes and the standard WordPress approach of adding HTML and CSS through a safe location such as Additional CSS, a child theme, or a trusted snippets tool. It does not modify the WordPress core, Gravity Forms, the theme, or the plugin.

/* Custom adaptation for the preview block.
   Basis: documented JetSloth classes gfcp_bg and scoped format gfcp_bg_{form_id}_{field_id}.
   Replace 12 and 4 with the actual form ID and field ID. */
.product-color-preview.gfcp_bg_12_4 {
  min-height: 180px;
  border-radius: 8px;
  border: 1px solid rgba(0, 0, 0, 0.12);
  display: flex;
  align-items: center;
  justify-content: center;
  color: #ffffff;
  font-weight: 600;
}

Where to place it: Appearance > Customize > Additional CSS, the child theme stylesheet, or another standard method for adding CSS on your site. The form HTML block or page should contain an element with the classes product-color-preview gfcp_bg_12_4. How to verify it: open the page, select a color in form ID 12, field ID 4, and confirm that the preview background changes. Rollback: remove the CSS and remove the class from the preview element.

When You Need a JavaScript Event

JetSloth also documents the gf-color-picker:picked event, which passes the selected hex value and the reference formID_fieldID. This is useful when simply changing the background, text, border, or SVG fill is not enough. For example, you may need to switch a product image, update a custom preview state, rewrite a hidden label, or synchronize several elements.

Add JavaScript only when it is truly needed. If the task is solved by a documented CSS class, there is no reason to add complexity. JavaScript breaks more easily: it may conflict with cache, deferred loading, repeated form embedding, or form updates after AJAX render. For a more advanced visualizer, it is usually safer to build a simple static preview first, add the handler second, and only then move it onto the live page.

Why Form ID and Field ID Matter More Than a Nice Selector

If a page contains multiple color fields, the generic gfcp_bg class listens too broadly. One selected color can end up repainting the wrong block. A scoped class with the form ID and field ID solves that: gfcp_bg_2_3 means the background should update based on form 2, field 3. That is not decorative precision. It is protection against unintended cross-connections.

Find the field ID in the Form Editor: select the field, look at its ID in the settings panel, or use the merge tag dropdown if you are configuring a notification. The form ID is visible in the form list and in shortcode or block settings. Keep both values documented next to the CSS so the next editor does not have to guess why the preview is listening to that specific field.

Using It Alongside Other Gravity Forms Solutions

Color Picker rarely works alone. A form may also use conditional logic, notifications, Image Choices, Populate Anything, WooCommerce add-ons, custom CSS, and spam protection. It is important to understand where each tool's responsibility begins and ends. Gravity Forms Color Picker handles color selection and the visual presentation of color. It should not replace dynamic data loading, price calculation, anti-spam protection, routing, or a full design editor.

Color Picker Plus Conditional Logic

Conditional logic helps reveal additional fields only for certain colors or for a custom choice. For example, if the user selects "Other," the form can show a HEX field and a comment field. If they choose "Black," you might show a production lead time note. But conditional logic depends on stable values. If the value contains special characters, HTML, or overly complex labels, the rules can become fragile.

Use simple values and test every branch. Do not stop after confirming that "the first color works." Check the first standard color, the last standard color, Other, an empty required field, switching back to a standard option after Other, and submitting the form after changing the selection.

Color Picker Plus Image Choices

JetSloth positions Color Picker as an add-on that grew out of the same thinking as Image Choices, and both the product page and related articles show combined workflows. Image Choices is useful when the user is choosing a visual object: an icon, a product card, a shape, a template, or a visual category. Color Picker adds the color layer to that object. In a logo designer or product configurator, that pairing feels natural: Image Choices handles the "what," while Color Picker handles the "which color."

Do not blur the roles. If the user is choosing a product image, do not make Color Picker imitate a product gallery. If the user is picking a shade, do not use Image Choices just to display colored squares. The clearer the boundary, the easier the form is to maintain and explain to the team.

Color Picker Plus Populate Anything

The JetSloth changelog includes GPPA integration, and the Gravity Wiz snippet library provides a separate compatibility snippet for the Color Picker choice template. That points to a practical workflow: choices may be loaded dynamically, and Color Picker still needs to understand which colorPicker_color value belongs to each choice. But this is already advanced configuration, where you need to verify compatibility with the exact versions and snippets you are using.

If you need a dynamic palette coming from entries, taxonomy terms, product data, or an external database, set up Populate Anything as the source of the choices first, then verify how colorPicker_color is attached to those choices. Do not promise an editor that "the palette will always update itself" until you have tested refreshing choices, preview in the editor, frontend rendering, the entry, and the notification.

Color Picker Plus Spam Protection

Color selection by itself is not anti-spam protection. Gravity Forms has its own spam detection tools, including honeypot support and spam entry behavior. Even if the form becomes more attractive and more distinctive, it can still receive junk submissions. So do not disable protection just because the form now includes a custom UI. Test the spam filter, notifications, and confirmation behavior separately.

Quality Checks After Configuration

After rollout, run a short QA pass. It should verify not only whether the form "looks good," but also the entire data chain. The sequence below is practical to repeat after updates to Gravity Forms, Color Picker, the theme, or a cache plugin.

Interface Check

• Swatches are visible on the public-facing site and in the form preview.
• Labels remain readable next to the color and do not disappear at mobile width.
• The selected state is easy to recognize.
• The custom color popup opens and closes as expected.
• Clear or Done behavior does not mislead the user if those elements are present in the current interface.
• The error message does not cover the swatches or unexpectedly reset the selected color.

Data Check

• The entry contains the selected label or value in the expected format.
• The Other choice preserves the custom value if that mode is enabled.
• Single Line Text stores the HEX value and does not leave a placeholder in place of a real value.
• The notification displays the color clearly enough that the recipient can act without opening the form.
• Conditional logic correctly shows and hides dependent fields.
• The export, CRM, or downstream add-on receives a stable value if it is part of the workflow.

Environment Check

Clear the page cache, browser cache, and CDN if one is in use. Then open the form in a normal browser session without logging into WordPress. Check multiple screen widths. If the site uses a page builder or a popup, test the final embedded location itself. Sometimes a form behaves perfectly in the editor, but inside a popup the initialization event fires before the field becomes visible.

If custom CSS is involved, disable it temporarily and see whether the issue changes. If the problem disappears, the cause is the customization rather than Color Picker. If the problem remains, look at legacy mode, asset enqueueing, a conflict with the theme framework, or third-party add-ons.

Signature Color Picker Behaviors Worth Testing Separately

The plugin includes several behaviors that make it a true Color Picker extension for Gravity Forms rather than just generic Radio Buttons styling. It is useful to test them as separate chains: where the setting lives, what the user selects, what the plugin changes, what outcome becomes visible, how a failure shows up, and where the limits are. This approach matters especially for agencies and sites with multiple forms, because a visual issue in one place can easily look like "the plugin is broken" when the real cause sits inside one specific chain.

Behavior 1: "Use Colors" on an Existing Radio or Checkbox Field

The setting lives inside a field that is already configured as Radio Buttons or Checkboxes. The person editing the form enables color behavior, assigns colors to the choices, and selects a display theme. The plugin turns ordinary answer options into color swatches, but the value behavior remains standard Gravity Forms behavior: one selection for Radio Buttons, multiple selections for Checkboxes.

The visible outcome is that the choices in the form become visual color samples. The verification step is to submit the form and open the entry. If the selected color is visible in the form but the entry does not contain the expected value, the place to investigate is not the display theme but the choice setup, "Other," required-state behavior, or custom JS. The limitation of this behavior is that it does not turn Radio Buttons or Checkboxes into a free-form palette editor. For arbitrary HEX input, use Single Line Text or a separate custom path.

Behavior 2: Free-Form Color Wheel in Single Line Text

The setting lives on a Single Line Text field. The administrator enables Color Picker, and the user gets a color-selection interface instead of a plain text input. The plugin stores the chosen shade as a text value, usually a HEX code. This is valuable when the downstream process needs an exact code rather than a label from a fixed list.

Failures show up differently than with swatches. If the popup does not open, check frontend assets, cache, JavaScript errors, and a builder conflict. If the popup opens but the entry is empty, check the required state, whether the field is being hidden by conditional logic, repeated form embedding, and whether a custom handler is overwriting the field value. The limitation is that Single Line Text does not provide a predefined choice palette. If you need a palette with several recognizable names, use Radio Buttons or Checkboxes instead.

Behavior 3: "Other" as a Controlled Exception

The setting lives in a Radio Buttons field where the "Other" choice is enabled. Combined with Color Picker, the user sees standard swatches and also gets the ability to enter a nonstandard color. In this workflow, the plugin preserves the core palette while still providing a path for requests that require manual handling.

There are three states you need to test: a standard color selection, Other with a filled custom value, and Other without a value. If a required field lets an empty Other submission pass through, the problem is in validation or in an incorrect assumption about expected behavior. If the Other value does not appear in the notification, check the merge tag and the email template. The limitation is that Other should never become a loophole around a real business constraint. If custom color is not actually possible, do not add the option just for the sake of "flexibility."

Behavior 4: Display Theme at the Field and Form Level

The theme setting may be global, form-specific, or specific to an individual field, depending on the current version of the plugin interface. JetSloth describes theme selection in the Color Picker tab inside the field settings sidebar and also refers to global color picker settings. In practical terms, that means you may pick one overall style but still adjust a specific field if its role in the form is different.

The visible outcome is a different presentation of choices: Pantone-style cards, circles, horizontal bars, compact chips, or lozenges. Failures usually appear as "the style did not change" or "the selected theme applies in the wrong place." Verification means resaving the form, clearing cache, confirming that legacy mode is not forcing the old behavior, and checking both preview and frontend output. The limitation is that a theme will not fix weak labels, too many choices, or a container that is too narrow.

Behavior 5: The Selected Color Controls Page Elements

This setting no longer lives only in the field settings. It also involves the page's HTML and CSS. JetSloth documents classes for changing background, text, border, and SVG fill based on the selected color. The user chooses a color in the form, the plugin passes that selected value along, and a class on a page element receives it as a visible output. This is the mechanism behind product visualizers and logo previews.

To verify it, follow the scoped path: pick the field, identify the form ID and field ID, add the class to the specific preview element, choose a color, check the result, submit the form, and then repeat the test after reloading the page. Failures show up as "the color changed the wrong block," "the preview reset after reload," "multiple blocks are listening to one field," or "the handler disappeared after AJAX render." The fix is usually scoped classes, checking the JS reference, avoiding repeated embedding of the same form on one page, and keeping custom code minimal.

Behavior 6: Swatch Display in Entries and Notifications

This setting controls how the chosen color appears after submission. According to JetSloth, the administrator can choose either standard text-based values or swatches in admin entries and email notifications. It does not change what the user clicks, but it strongly affects how the team processes submissions.

Verification should include one submission with a standard swatch, one with Other, and one with a Single Line Text HEX value. Open the entry detail, the entry list if it is used, the admin notification, the customer notification, and any routing recipient. Failures show up as "the email only shows a color block with no name," "the entry has the label but not the HEX value," or "the color looks different in email than it did in the form." The fix is to combine label and value, use clear merge tags, and keep the swatch as an extra visual layer rather than the only source of meaning.

These six behaviors work well as a checklist after each update. If you know which exact chain broke, troubleshooting becomes short and focused. If you describe everything as "color selection is not working," you are likely to start randomly switching themes, cache settings, snippets, and conditional logic without understanding which piece actually controls the symptom.

How to Fit Color Selection Into the Team Workflow

The form does not end at Submit. After submission, someone reads the request, sorts it, turns it into a task, checks it against a catalog, replies to the customer, or passes it to a designer. Gravity Forms Color Picker only improves that process when the selected color becomes a clear working signal. If the entry looks nice but the manager still has to email the customer asking "which blue did you mean," the setup is not finished yet.

For the Manager: The Color Should Be Readable as an Action

A manager usually does not need a CSS code by itself. They need an answer to the question, "What happens next?" That is why the notification should place an action next to the color: a standard option means check availability, a custom HEX means review the shade, multiple colors mean confirm priority, low contrast means send it to the designer. This can all be handled with plain text in the notification template without complex code.

An example email workflow might look like this: "Primary color: Orange. Status: standard palette. Action: check material availability." For the custom path: "Primary color: Other. HEX: #4c6a86. Action: review custom shade." That structure reduces dependence on how the email client renders the swatch.

For the Designer: HEX and Context Matter More Than a Decorative Card

A designer needs the exact color value and a clear understanding of where it will be applied. If the form is collecting a brief, add separate fields such as primary color, background color, text color, and accent color. Do not try to keep all colors in one Paragraph Text field, because they become hard to use in merge tags and entries later. Single Line Text with Color Picker is well suited for each separate HEX value.

If the selected color should affect a preview, add a simple visual block through the documented classes. But do not imply that the preview is the final mockup. State in the form or confirmation that the color is only a guide and that final review still includes contrast, material, print output, or the design system.

For the Developer: Fewer Global Selectors, More Scoped Targeting

The developer's job is to protect the form from side effects. A global gfcp_bg class is convenient in a demo, but on a live site it is better to bind the preview to a specific form ID and field ID. Custom CSS and JS should live in a place where they can be disabled cleanly: a child theme, a snippets manager, a separate enqueue in the theme, or a documented custom code area in the builder. Do not paste code into a random HTML block if no one will know where to find it later.

For each custom fragment, document why it exists, which field it listens to, which IDs it uses, where it is stored, how to test it, and how to roll it back. That is simple engineering discipline, but it is especially useful in Gravity Forms projects where forms are often edited by more than just developers.

For Support: The Entry Should Explain the Issue Without the Layout

When a client says "the color was wrong," support should be able to quickly see what was selected: the label, the value, the custom HEX, the conditional logic branch, the timestamp, and the page URL. Gravity Forms merge tags and entry details make it possible to collect that in a notification or internal note. If a visualizer is involved, add a manual check to the process: verify that the HEX value in the entry matches the preview color that should have been shown.

If the issue repeats, ask the user for the browser and the exact steps, but start with your own data first. The entry shows whether the field was submitted. If the field is empty, investigate the form. If the entry contains the correct HEX but the manager sees a different color in the email, investigate email rendering. If the entry and email are correct but the product preview looked different, investigate the custom CSS or JS.

For the Site Owner: When to Call the Rollout Successful

Success is not about having more attractive swatches. Success means fewer clarification emails, fewer incorrect requests, clearer choices for the user, and faster processing for the team. After launch, review the first real submissions. If many users choose Other, the standard palette may be too narrow. If users choose custom HEX values that cannot actually be fulfilled, the field description needs to change. If managers ignore the swatch and recheck everything manually, the notification needs to be clearer.

That kind of review is more useful than endlessly rotating display themes. Visual styling matters, but in a form it serves a working purpose: helping the user choose and helping the team process the submission without guesswork.

Troubleshooting: When Swatches, the Popup, or Color Saving Do Not Work Correctly

Color Picker issues almost always happen at the boundary between the Gravity Forms field, the plugin setting, the theme, cache, and custom customization. To avoid wasting time on random toggles, troubleshoot the symptom as a chain: where the error appears, what should have happened, which setting controls that piece, and how to confirm the fix.

Swatches Do Not Appear on the Site

Symptom: the field is configured in the form editor, but on the public page the user only sees ordinary radio buttons or checkboxes. Possible causes: "Use Colors" is not enabled for the correct field, the wrong form is embedded on the page, assets did not load because of cache, the page is showing an older saved version of the form, or the theme's custom CSS is overriding the swatch layout.

What to check: open the field settings and confirm that Color Picker is enabled for that exact field ID. Then open the form preview. If the preview works but the page does not, the issue is at the page, cache, or builder level. Clear the cache, temporarily disable CSS and JS minification for that page, and test the form without a popup and without embedding it twice on the same page.

How to fix it: enable colors on the field, resave the form, clear the cache, verify asset enqueueing, and temporarily remove conflicting CSS. If the form is older and visual issues appeared after an update, check legacy mode as described in JetSloth documentation.

The Color Wheel Opens, but the Value Is Not Saved

Symptom: the user selects a color and sees it in the field, but the entry is empty or contains the wrong value. Possible causes: the field is hidden by conditional logic at submit time, custom JS changes the input after selection, the form contains a duplicated field ID because it was embedded repeatedly, or the user selected "Other" but did not fill the associated input.

What to check: submit the form while the field is visible and active. Temporarily disable any custom JS listening to gf-color-picker:picked. Check whether the form is embedded twice. For Radio Buttons with "Other," make sure the custom value is actually entered and that required validation is not allowing a placeholder through.

How to fix it: simplify conditional logic, remove repeated embedding, scope the JS to a specific form ID and field ID, add a clearer description for "Other," and verify the entry after each change.

After an Update, the New Themes Are Gone or the Form Looks Old

Symptom: Color Picker still works, but the newer display themes or layout settings do not apply, or the form looks like it did before the update. A likely cause is legacy mode. JetSloth documentation on new styles and settings explains that after a major update, legacy mode may have been enabled by default to provide a softer transition.

What to check: open the global Color Picker settings and look at legacy mode. If it is enabled, the newer features may be turned off. Before switching it, test on staging or on a copy of the form, because legacy mode may be protecting an older form from visual changes.

How to fix it: disable legacy mode only after testing, resave the form, and check the editor preview, public page, entry, and notification. If the older form breaks, temporarily restore legacy mode and plan a gradual CSS adjustment.

Swatches Look Bad on Mobile

Symptom: everything looks neat on desktop, but at mobile width the swatches are too small, labels wrap awkwardly, or the selected state is hard to notice. Causes may include too many columns for tablet or mobile, a compact theme with not enough supporting text, a narrow popup container, or theme CSS conflicts.

What to check: layout settings for desktop, tablet, and mobile, the selected display theme, container width, and custom CSS. Use the real page, not just the editor preview. If the form appears in a sidebar or modal, the mobile issue may show up earlier than it does on a normal page.

How to fix it: reduce the number of columns, switch to a less dense theme, increase spacing through scoped CSS, move the form into a wider block, or split the choices into logical groups. Rollback: restore the previous display theme and remove the custom CSS.

The Notification Displays the Color Poorly

Symptom: the entry looks fine, but the email shows only the label without the color, only the HEX value without context, or the swatch looks strange in the email client. Causes include the wrong output format, a merge tag inserted without the label, an email client simplifying HTML, or the recipient needing a different format of information.

What to check: the notification template, merge tags, the swatch or text display mode, and different email clients. Send a test email both to an administrator address and to a normal mailbox. Compare the result with the entry detail.

How to fix it: include both the label and the value, keep the swatch as an extra visual cue, and separate the admin notification from the customer-facing confirmation if necessary. If the email goes into a processing system, use a stable text value.

The Custom Visualizer Changes the Wrong Element

Symptom: the selected color repaints several blocks at once, affects the wrong preview, or changes elements belonging to another form. The cause is usually an overly broad class such as gfcp_bg, gfcp_color, or a JS handler that does not verify the reference.

What to check: how many color picker fields are on the page, which form IDs and field IDs are in use, and whether the same form appears both in a popup and on the page at the same time. If the gf-color-picker:picked event is used, check the ref argument.

How to fix it: replace the generic class with the scoped format gfcp_bg_{form_id}_{field_id}, limit the JS handler to a specific reference, duplicate the form instead of embedding one instance multiple times, and clear the cache after changing CSS or JS.

Safe Improvements You Can Make Without Editing Core Files

Color Picker already includes ready-made display themes, layout settings, and documented hooks and classes. That means most improvements should happen through settings, scoped CSS, or a small handler, not by editing plugin files directly. Editing the WordPress core, Gravity Forms, the theme, or the JetSloth add-on creates a risk of losing changes during updates and makes long-term support harder.

Change the Label of the Color Picker Action Button

JetSloth documents the PHP filter gf_colorpicker_action_label for the single picker used with a text field. You can use it if the default label does not fit the site's language. This is a documented extension point, but it should still be applied carefully, preferably through a child theme or a snippets plugin that can be disabled cleanly.

<?php
add_filter( 'gf_colorpicker_action_label', 'site_gf_colorpicker_action_label' );

function site_gf_colorpicker_action_label( $value ) {
    return 'Choose Color';
}

Where to place it: the child theme's functions.php or a trusted snippets tool. How to verify it: open a Single Line Text field with Color Picker enabled, confirm that the label changed, then submit the form and check the entry. Rollback: disable the snippet or remove the filter.

Color Forms and Accessibility

If color is an important choice, add a visible text label and do not hide it for the sake of minimalism. For a free-form HEX field, add a description that explains the expected value format. For swatches with similar shades, use labels that differ in wording, not just in color: "Dark blue," "Light blue," or "Blue gray." A site may show user-facing labels in its own language, but the underlying technical values are usually best kept stable.

If you use CSS clip-path, as shown in the JetSloth tutorial, test the ordinary theme first before adding the shape. CSS shapes can make the form look more expressive, but they may hurt readability if the selected state, focus state, and hover state are not clear enough.

Do Not Add a Heavy Visualizer Without a Real Need

A product visualizer can look impressive, but it requires extra support work: product images, matching the number of colors to the number of images, checking indexes, handling the initial state, managing the mobile layout, and maintaining compatibility with caching. JetSloth's tutorial explicitly uses custom CSS and JS. For a simple order form, swatches, labels, and a clear notification are usually enough. Build a visualizer only if it genuinely helps the user understand the outcome before submitting.

Questions Worth Answering Before the Form Goes Live

Can I Add Color Picker to Any Gravity Forms Field?

No. Official JetSloth sources and the Gravity Forms marketplace listing identify support for Radio Buttons, Checkboxes, and Single Line Text. The changelog also mentions Multi Choice field support, but for everyday setup, rely on the documented fields and verify the current documentation for the exact version you are using.

Which Is Better: Radio Buttons or Single Line Text?

Radio Buttons are better for one color selected from a prepared palette. Single Line Text is better for a free-form HEX value. If the business supports only a limited set of colors, do not offer a full color wheel without a reason. If the workflow is creative and the user needs to choose the exact shade, Single Line Text is usually the better fit.

Can the Selected Color Be Shown in an Email?

JetSloth states that swatches can appear in admin entries and email notifications. But email should always be tested separately because different email clients may render HTML differently. For important requests, include the text value next to the visual swatch.

Why Do the New Themes Not Apply After an Update?

Check legacy mode. JetSloth documentation on new styles and settings explains that legacy mode may have been enabled to provide a smoother transition after a major update. Disable it only after testing the form, because older CSS customizations may depend on the previous behavior.

Does Color Picker Affect Site Performance?

The JetSloth changelog includes updated enqueue conditions so assets load on the frontend only when the form contains color picker fields. That is a good sign, but you should still measure performance on your own page, especially if caching, minification, and a page builder are in use.

Can the Selected Color Be Used to Change a Block on the Page?

Yes. JetSloth documents the classes gfcp_bg, gfcp_color, gfcp_border, gfcp_fill, and the event gf-color-picker:picked. Start with scoped CSS classes, and add JavaScript only if simple color changes are not enough.

What If a Custom Color Is Needed Only Sometimes?

Use Radio Buttons with "Other" and conditional logic. The standard palette stays primary, while the HEX field and comment appear only when the custom path is selected. That keeps the form lighter for most users without losing unusual requests.

Is the Plugin Suitable for a Full Online Designer?

For simple visual selection and preview, yes, especially when paired with CSS, JS, and careful testing. For a complex editor with layers, image export, precise layout control, and design file storage, Color Picker alone is not enough. It can be part of the solution, but not the entire system.

When Gravity Forms Color Picker Is the Right Choice

Gravity Forms Color Picker is a strong option when color selection truly affects the request, the order, the brief, or a visible outcome. Its main strength is that it extends familiar Gravity Forms fields instead of forcing you to build a separate system. You can start with a simple form: one Radio Buttons field with swatches, verify the entry and notification, then add a Single Line Text field for HEX, a display theme, layout settings, and a scoped visual preview if needed.

If you need a controlled color choice, use Radio Buttons or Checkboxes and think through the labels and values in advance. If you need a custom shade, use Single Line Text and explain the expected format. If the selected color should affect a page element, build on the documented JetSloth classes and events, but keep the customization small, reversible, and tied to a specific form ID and field ID.

Before launch, always test the whole form: the public-facing page, mobile width, the entry, the notification, the confirmation, conditional logic, cache, and custom CSS. If that full pass is clear and the team knows how to read the outcome, you can move on to the product file and download the WordPress version for testing on your own site.

The conclusion is straightforward: the plugin works best when color is part of the user's actual decision. If color helps choose a product, describe a design, confirm a shade, or show a preview, Color Picker adds clear working behavior to the form. If color does not affect how the submission is processed, it is usually better not to complicate the form and to keep the user's focus on the main action.