Color filters don't work with hex values from metaobjects

Topic summary

A developer encountered an issue where Shopify’s color_brightness filter fails when applied to hex color values retrieved from color metaobjects, despite the values appearing correct (e.g., #000000).

The Problem:

  • Direct output of color_code displays #000000 correctly
  • Applying color_brightness filter to this variable returns blank/nothing
  • The same filter works when applied to the literal string '#000000'

Solution Found:
String pseudo-coercion resolves the issue: {{ color_code | append:"" | color_brightness }} forces the value into a proper string format before applying the color filter.

Root Cause:
Shopify’s documentation states color metaobjects output “hexadecimal color codes,” which should be strings, but they apparently aren’t treated as true strings internally. This requires explicit type coercion despite the misleading documentation.

Additional Context:

  • Liquid lacks robust introspection tools compared to JavaScript/PHP
  • The | json filter and custom Liquid REPL tools can help debug variable types
  • Participants suggest reporting this as a documentation bug or usability issue to Shopify support
Summarized with AI on November 7. AI used: claude-sonnet-4-5-20250929.

I’m using category metafields to handle variant colors. In my theme, I get hex values from color metaobjects to set swatch colors. That works great. But for some reason, color filters do not work on these hex values.

// Get a hex color code from a color metaobject.
{% assign color_code = product.metafields.shopify.color-pattern.value[0].color %}

{{ color_code }} // Output: #000000

{{ color_code | color_brightness }} // Output: nothing (blank string)

// This works fine.
{{ '#000000' | color_brightness }} // Output: 0.0

As far as I can tell, color_code === ‘#000000, so why does the filter work on the string but not the variable?

Hi @diegovogel Also try non-black colors to see if result changes,

Check if string pseudo-coercion {{ color_code | append:“” | color_brightness }} works.

Or I doubt it but try yet another .value {{ color_code.value | color_brightness }},

Because .value is shopify liquid’s newest bugbear when coding , and that’s ontop of shopify making some objects default to weird ~string/not~string outputs when called directly instead of the object, or properly defined properties like the color object for “convenience” or “compatibility” reasons

https://shopify.dev/docs/api/liquid/objects/color#color-referencing-color-settings-directly

To roll your own brigthness the forumula is : ((Red value X 299) + (Green value X 587) + (Blue value X 114)) / 1000

@PaulNewton the pseudo-coercion worked! I’ve never seen that before in Liquid. Is it basically typecasting?

@PaulNewton Side note: it has always been awkward/painful to inspect values in Liquid IMO. At least compared to other contexts like JS and PHP. The new theme console command is helpful, although somewhat buggy in my experience. And outputting to the page only works for strings. Do you have any other tips for inspecting variables/objects?

Not really a low level concept of programmatic “types” in liquid it’s a template language

, but outputs sometimes need a push to strings , as do INTs sometimes: {{ “1” | plus: 0 }} == 1

Note metafield “types” etc don’t count as typecasts either.

The annoying thing here is the docs specially say that it outputs a “hexidecimal color code” which intuitively any sane person would assume is already a string but noooooo it’s not really in this case.

If you have the time on the docs there is a feedback action: “Was this section helpful? Yes No” , to explain this confusion.

Or if you have the time to champion it make a minimum reproducible case and either submit a complaint to shopify support about confusing color system usage ,or argue that it’s a bug* the way it works in practice and how it’s presented.

, or use your partner dashboard to submit a bug report to shopify partner support.

Just keep in mind compiler jocks at shopify will probably just say it’s “working as intended” , ignoring the confusion and how it needs to be used in reality.

Shopify has no real introspection for liquid processing not even source maps(for liquid),

You can use the | JSON filter etc on some objects and properties to get structure data or to diagnose properties though some objects do not work with the JSON filter; and no there is no documented list of which do and dont.

In themes it can help to setup a dedicated page with a custom-liquid section using the visual theme editor for testing liquid insitu.

There’s also setting up your own proxy app as a browser REPL

example https://shopify-liquid-repl.tomblanchard.co.uk/